[klibc] klibc and what's the next step?
jbailey at ubuntu.com
Sat Jul 1 03:56:57 PDT 2006
Le vendredi 30 juin 2006 à 16:15 -0700, H. Peter Anvin a écrit :
> Michael Tokarev wrote:
> > Pavel Machek wrote:
> > [klibc/kinit in kernel]
> >> I'd like to eventually move swsusp out of kernel, and klibc means I
> >> may be able to do that without affecting users. Being in kinit is good
> >> enough, because I can actually share single source between kinit
> >> version and suspend.sf.net version.
> > Heh. Take a look at anyone who's using real initramfs for their boot
> > process. Not initrd, not kernel-without-any-preboot-fs, but real
> > initramfs. For them, if kinit/klibc will be in kernel, nothing changes,
> > because their initramfs *replaces* in-kernel code and future supplied-
> > with-kernel-klibc-based-kinit. So if you'll move swsusp into kinit,
> > it WILL break setups for those users!.. ;)
> Either the kernel can unconditionally invoke /kinit, which then would
> invoke the users /init if present, or the swsusp can be a separate
> initramfs binary which the user's initramfs gets to invoke (the second
> is arguably neater, but requires minor changes to the users initramfs.)
The Ubuntu initramfs doesn't use kinit, and it would be nice if we
weren't forced to. We do a number of things in our initramfs (like a
userspace bootsplace) which we need done before most of the things kinit
wants to do take place.
kinit is a nice default tool but longer term, I almost imagine it as a
busybox type of setup. Either you say "go" and it brings up the system,
or you call it with an argument, change argv or something to get just
the functionality asked for.
* Canonical Ltd * Ubuntu Service and Support * +1 514 691 7221 *
Linux for Human Beings.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: Ceci est une partie de message
Url : http://www.zytor.com/pipermail/klibc/attachments/20060701/7b4eb711/attachment.bin
More information about the klibc