Re: klibc and what's the next step?

[Pavel Machek]

Hi!
> > So anyone who likes to see klibc merged, because it will solve some kind 
> > of problem for him, please speak up now. Without this information it's 
> > hard to judge whether we're going to solve the right problems.
> 
> I do not want to see kinit merged.
> It (the merge into linux-2.6.XY) doesnt solve any real problem in the long term.
> Instead, make a kinit distribution. Let it install itself into an obvious
> location on the development box (/usr/lib/kinit/* or whatever), remove all
> code behind prepare_namespace() and put a disclaimer into the Linux 2.6.XY
> releasenote stating where to grab and build a kinit binary:
> make && sudo make install
> It can even provide its own CONFIG_INITRAMFS_SOURCE file, so that would
> be the only required change to the used .config.
> 
> 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

That is the problem... kernel did not use to depend on kinit, and this
is considered stable series. So if kernel wants to depend on kinit, it
needs to ship it itself.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/