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

[Michael Tokarev <mjt@tls.msk.ru>]

Jeff Garzik wrote:
[]
>> But so far, the arguments are not convincing that kinit has to be in the
>> kernel tree.
> 
> Two are IMO fairly plain:
> 
> * Makes sure you can boot the kernel you just built.

Nowadays, less and less setups will Just Work without additional
help.  softraid/lvm (yes I know about raid-autodetect, which should
DIE better sooner than later, due to its brokeness), firmware loading,
DSDT table updates, iSCSI and what not.

So, by just moving stuff to kinit and providing it with kernel
solves nothing in this area.

Yes, there's a very tiny difference between in-kernel kinit and
external kinit: I mean, external kinit has a >< bit more chances
to be incompatible with new kernel than kernel-supplied one.
But so are other tools and libraries, listed in Documentation/Changes.

> * Makes it easier to move stuff between kernel and userspace.

Again, not an argument to have kinit to be supplied by kernel.
Or, rarther, not strong argument.

It'd be much easier to "test" some stuff and to shuffle things
between kernel and user spaces if kinit is a part of kernel.
Like, move things to kinit, discover it does not quite work,
move some stuff back, etc.  With external kinit that will not
be easy, and kinit will grow indefinitely, accumulating all
the various compatibility/testing cruft.

But that's not how things should be done IMHO.  Testing/planning,
that is...

And again, how much stuff it's possible to shuffle this way?
How many new concepts *can* be moved from kernel to kinit,
anyway?  Uswsusp has been mentioned.  Anything else?

/mjt

-
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/