Re: [klibc] klibc and what's the next step?

[Olaf Hering <olh@suse.de>]

 On Tue, Jul 11, Michael Tokarev wrote:

> kinit SHOULD go with kernel. To stay compatible, to be able to move some more
> stuff to it from kernelspace with time, and so on.

compatible with what? What changes do you expect that will break kinit
as we have it right now?

> The question was about klibc, not kinit.

klibc without user is really pointless.

> > The rationale is that there are essentially 2 kind of consumers:
> > 
> > One is the kind that builds static kernels and uses no initrd of any kind.
> > For those people, the code and interfaces behind prepare_namespace() has
> > not changed in a long time.
> > They will install that kinit binary once and it will continue to work with
> > kernels from 2.6.6 and later, when "/init" support was merged. Or rather
> > from 2.6.1x when CONFIG_INITRAMFS_SOURCE was introduced.
> 
> And stuff will break on them after eg uswsusp move into kinit etc.

Why? If they want that new feature:
download kinit-2.0, make && make install. That concept is not new.
kinit-2.0 will surely be compatible with what is required for last years
kernel because its not maintained by the-average-udev-developer kind of
people.

> > The other group is the one that uses some sort of initrd (loop mount or cpio),
> > created with tools from their distribution.
> > Again, they should install that kinit binary as well because kinit emulates
> > the loop mount handling of /initrd.image. This is for older distributions
> > that still create a loop mounted initrd.
> 
> There's no need for loop-mounting of any initrd.images.  Initramfs (cpio image,
> possible gzipped) works just fine, and it will NOT go away because something
> should do the unpacking/loading of that image so that kinit &Co will run.
> There's no need for old initrd+pivot_root at all.  Only the ones who are,
> for some reason, didn't switch to initramfs yet.  And I personally see no
> reasons not to switch - initramfs (rootfs) concept is much more clean and
> easy to handle and gives more possibilities than initrd.

Are you saying that everyone now suddenly is forced to use a cpio image?
Why did hpa add the loop mount code to kinit?
So if you force people who build kernels to use newer tools, one more
external binary will surely not hurt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/