Re: klibc (was: 2.6.18 -mm merge plans)

[Roman Zippel]

Hi,

On Sun, 4 Jun 2006, H. Peter Anvin wrote:

> Andrew Morton wrote:
> > 
> > git-klibc.patch
> > 
> >  Similar.  This all appears to work sufficiently well for a 2.6.18 merge.
> > But it's been so long since klibc was a hot topic that I've forgotten who
> >  wanted it, and what for.
> > 
> >  Can whoever has an interest in this work please pipe up and let's get our
> >  direction sorted out quickly.
> > 
> 
> klibc (early userspace) in its current form is fundamentally a cleanup.  What
> it does is unload code from the kernel which has no fundamental reason to be
> kernel code (written during kernel rules, with all the problems it entails.)
> The initial code to have removed is the root-mounting code, with all the
> various ugly mutations of that (ramdisk loading, NFS root, initrd...)

For a cleanup it adds quite a lot of code, where I'm not really sure it 
should all be distributed with the kernel. I'm really surprised there 
hasn't been any larger discussion about or maybe I missed something?

It adds various utitilies (dash, gzip, ...) to the kernel source, which 
are not kernel specific at all. Why do we need this duplication? IMO code 
duplication like this is not a desirable thing, as it increases the 
maintenance overhead. Sometimes this is necessary, but IMO it should have 
a good reason and should be temporary. Where does this duplication end 
(e.g. udev, module tools), are we going to pull everything into the kernel 
source, which might be needed for an initramfs?

I think the most questionable duplication is the libgcc copy. Why do you 
even provide your own copy of this? This is a private library of the 
compiler and the last thing I would duplicate.

How is this going to integrate with the rest of the system, especially on 
the distribution side. They have their own mechanisms to produce an 
initrd. What happens if NFS root requires a network module, which requires 
a firmware file? How is this going to work?
How can e.g. embedded users control what's going into the initramfs, they 
certainly don't want any duplication here (e.g. initrd on top of 
initramfs?)

I'm not really comfortable with merging the whole thing at once, it's a 
huge patch (or thousands of little commits) with no real documentation, 
which makes it very hard to review. IMO it would be preferable to 
distribute the non-kernel specific parts separatly and make this more 
modular, so that the user can exchange any part he like. The patch also 
already removes a lot of the old setup stuff, which makes it an 
all-or-nothing approach. It doesn't leave us with the possibility to make 
the new setup optional and gradually convert the various boot 
initialization to it and experiment a little with it at first (not just 
kernel developer but also everyone else).

Considering the impact all these changes will have, I would be really 
interested in more opinions on this or just does everyone hope it will 
somehow work out by itself?

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/