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

[Greg KH]

Ick, please fix your email client to properly format your long lines
(i.e. no line wrapping.)  I've reformatted them below to be sane...

You also took the thread off of gentoo-dev, that's not nice either...

On Sun, May 02, 2004 at 10:20:39PM -0600, Joshua Campbell wrote:
> On Sun, 2 May 2004 20:56:47 -0700
> Greg KH <gregkh@g.o> wrote:
>
> > 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?
> >
>
> Yes, we will probably hook into the alread existing configure system.

That is not what you were stating.  Please document this if it is going
to be so.

> The extra tool isn't much more than a wrapper for it, however it is
> needed so that portage can manage the kernel configs [supply the
> config when the kernel is built, when modules are built, when a newer
> kernel is configured, when the kernel is rebuilt, when the initrd is
> built].

initrd has nothing to do with the kernel config.  Also see my previous
comments about initrd going the way of the dinosaurs...

> > > 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?
>
> With genkernel, yes, we are just simply using this ability of
> genkernel's in a more modular fasion.

Again, your proposal never said anything about using the current
genkernel functions or functionality.  Again, please revise it if this
is going to be so.

> You do not need the whole tree around to build modules.  For example,
> an x86 system would never need the sparc-specific parts of the kernel
> to build module.

Down this path lies madness...  Trust me, see the zillion different
threads about this very topic on the linux-kernel mailing list.  Also
note that the majority of files in the kernel source tree are not in the
arch specific portion, but rather in the drivers/ section.

You need a good portion of the tree to build modules.  This is easily
proved with a simple test.  Also see my previous comments about the
infeasibility of handing this when trying to build other packages that
want kernel source present somewhere...

> Yet again, we aren't scrapping genkernel, we're enhancing it.

Again, this is the first time this has been mentioned.

In fact, to quote the GLEP:
	This GLEP hopes to overcome this by abstracting the various
	layers of genkernel and implementing the most common aspect (the
	build procedure) into a portage eclass.

That sure doesn't sound like "enhancing" genkernel.  Sounds more like
grabbing the genkernel code and reforming it into something else at the
very best reading.

> > > 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?
> >
>
> This is an example.  USE flags would not be used to configure the
> kernel, but rather dependancies as shown above.

So are you stating that "bootspash" and "initrd" are going to be the
only dependencies?  You do realize that the "bootsplash" option requires
a kernel patch to be applied?  If I don't specify the "bootsplash"
option, I sure don't want that patch applied to my kernel (perhaps
because I live in a place that decrees that this specific patch is
illegal...) 

"bootsplash" also affects the kernel config options.  As does "initrd",
correct?  So how can you state that these flags will not be used to
configure the kernel when your example clearly shows them doing so?

Also, what happens if a security fix is needed that is around the same
portions of the kernel code that the bootsplash code is at?  That would
require 2 different security patches to be in the repository, and 2
different tests to determine if the patch works properly or not.

Multiply this by a zillion different "requests" that I know we will get,
and it will quickly get unwieldy.

For example, we currently have a "usb" use flag.  Should the kernel
build process honor it?  If so, does that mean we need to split the
existing lirc patch up into 2 pieces (one for the usb driver, and one
for the rest)?

That's what I am talking about when I mention the total ickyness that
will ensue if we try to use USE flags to modify the kernel build
process.

> > 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.
>
> Modularing the initrd system will only help us prepare for this eventuality.

Huh?  It isn't already in the genkernel tool?  What is the function
"create_initrd" used for?  :)

> > > 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.
>
> It is easier to port things in parts ["configs" and initrd] than it is
> as a whole.

But this proposal says nothing about porting "things in parts".  It
talks about a replacement for our current kernel build system.

> > >	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.
>
> If initrd goes away we will NEED that flexibility.

What flexibility?  initramfs works on every platform and provides _more_
flexibility.  I don't understand your objection here.

> It will be easier to create a reference implementation if developers
> such as yourself will have open mind.

I have a very open mind.  I'm trying to show the problems I see in this
proposal (which is why you all posted it, correct?)  That's part of the
review process.  Hopefully in the end something better than a person
working by themselves will be created.  That's the main strength of open
source development.

So that's about it for my objections.  I eagerly await your reference
implementation, and your revised GLEP proposal based on this
implementation.  As the GLEP process states:

	The GLEP should be reviewed and accepted before a reference
	implementation is begun, unless a reference implementation will
	aid people in studying the GLEP. Standards Track GLEPs must
	include an implementation -- in the form of code, patch, or URL
	to same -- before it can be considered Final.

For this GLEP, I propose that a reference implementation is necessary
before we can properly study this GLEP and see if it is acceptable or
not.

Any objections?

thanks,

greg k-h

--
gentoo-dev@g.o mailing list