Re: [gentoo-dev] GLEP 26 -- Handling kernels with portage

[Greg KH]

On Sun, May 02, 2004 at 10:04:35PM -0400, Nathaniel McCallum wrote:
> The new glep is here: http://www.gentoo.org/proj/en/glep/glep-0026.html

My formal objections:

Basically the idea is nice, but I think the proposed solution is not
correct.  Here is why I feel this way:

> Stage 1 would be achieved through a seperate utility (perhaps like the
> current genkernel). This utility would help the user configure the
> kernel and any kernel/build related settings. This stage is optional
> and would only be used if a person wanted a customized kernel
> settings. One optional thought is to have this utility a part of the
> base Gentoo system. That way there are less steps to make a custom
> kernel.

Why reinvent the wheel here?  The kernel has a _wonderful_ configuration
system already.  It's provided in about 4 different interfaces at least
(command line, ncurses, gtk, qt), and in library form.  Are you
proposing hooking into that library to do the configuration?  If so,
what is lacking in the current implementation that is needing another
tool?

> Stage 2 would be implimented through an eclass. This stage is not
> optional. One would perform this step by typing "emerge kernel-name",
> where "kernel-name" is the name of the kernel package you want to use
> (ie. "gentoo-dev"). This package would have a "buildkernel" USE flag.
> If the flag was not set, it would simply download and install sources
> like we do currently. However, if the "buildkernel" flag is set,
> portage will perform the following steps:
>
>	1. (as a dependency) download and install a tarball of "generic"
>	   kernel config files.

Is this really needed?  Don't we already do this today?

>	2. Check to see if customized kernel config/settings have been
>	   set via Stage 1.
>	3. Portage will use a custom config, if available.  Otherwise, a
>	   "generic" config.
>	4. If neither a custom config or a "generic" config is
>	   available, die (with message).  This is needed as some arches
>	   don't/can't have "generic" configs, so they will simply be
>	   presented a message telling them to run the utility from
>	   Stage 1 (which they obviously skipped).
>	5. Build the kernel and modules and install them
>	6. Remove unnecessary files from the sources and tarball it as
>	   "kernel-headers". This tarball provides the appropriate files
>	   to build external modules against, like nvidia-kernel, etc...
>	   The external modules (when built) will determine the running
>	   kernel and unpack the appropriate tarball, to build against,
>	   then remove the files.

Does this work?  As specified before, I really think you need the whole
tree around in order to build external modules.  Now with 2.6, building
those modules is a world easier (1 line makefile), and it works if you
are not root (no write access necessary).  But again, all of this is
already being addressed in the genkernel rewrite that is happening (and
you can see it already in cvs.)

> Stage 3 would merely be an ebuild that constructs an initrd image for
> either the running kernel or, lacking a running kernel, the newest
> kernel installed (by version/date installed?). Initrd's can't be used
> on all arches, so this ebuild can be keyword masked as appropriate.
> The initrd package would also have a "bootsplash" USE flag (on x86,
> maybe others) that would build in bootsplash support. Any non-default
> actions desired by the user can be handled with the utility from Stage
> 1.

So "bootsplash" will be the only USE flag?  Why stop there?

Oh, and initrd images are dead.  I predict that by the end of this year
we will not be using them at all, as there is no need to (other distros
are already proving this is possible.)  We also get a much more
flexible, portable (works on all platforms) and cleaner implementation
with initramfs, so that is what we will be moving to soon.  So your
"initrd" options are pretty moot.

> There are many advantages gained by this method:
>
>	1. Full arch support (GentooInstaller really could use this)

We should fix genkernel to do this, if it doesn't already today.  There
is no reason this should not be possible today without a total rework.

>	2. More consistent with the rest of portage (installs binaries
>	   by building from source)

True, it isn't as "clean"

>	3. Better user experience

You forgot "mom and apple pie" here too :)

>	4. More flexability (genkernel forces building of initrd on x86)

I've already outlined the issues of initrd going away, so this isn't an
issue.

>	5. Don't have to store full kernel sources (each source tree is
>	   ~200MB unpacked)

You don't have to that today if you don't want to build any other kernel
modules that are outside of the main kernel tree.  I have a number of
boxes set up this way right now.  In fact, those boxes do not even have
a single kernel package on them at all, I just rolled my own and
installed it.  Once of the niceties of Gentoo is that you do not have to
install a Gentoo kernel in order to have a working box (which for my
job, is a very good thing.)

But yes, there are a few packages that want to use kernel header files
in their build process, but that's another issue to deal with and take
care of...

>	6. Creates the ability to make binary kernel packages for fast
>	   installs (think GRP kernel)

I see no where in your proposal for how this will be accomplished.  In
fact, this is the first place in the GLEP that "binary kernel packages"
are even mentioned.  Please either add the description of how you are
going to do this to the SPECIFICATION portion of the document, or take
it out of the RATIONAL portion.

>	7. A seperate package for "generic" kernel config files gives us
>	better version tracking

"better version tracking"?  What do you mean here?  Kernel config files
can not be kept identical across 2 different kernel versions.  And they
are not supposed to be.  They are a vital portion of the kernel version
itself and can not be split out.  To think otherwise is to not fully
understand the kernel build process.

Also, is this a problem today?  I have not seen issues related to this
in the past, have you?  Are there any bugs you can point us at that
would show how this would help out?


So in summary, again, I understand the objections to the current
situation.  However I do not see how the proposal really helps solve the
issue.  If a reference implementation was created it would be easier to
discuss it at that time.

thanks,

greg k-h

--
gentoo-dev@g.o mailing list