Messages in this thread |  | | | Date | Sat, 01 Jul 2006 06:56:57 -0400 | | From | Jeff Bailey <> | | Subject | Re: [klibc] klibc and what's the next step? |
| |
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[0] or something to get just the functionality asked for.
Tks, Jeff Bailey
-- * Canonical Ltd * Ubuntu Service and Support * +1 514 691 7221 *
Linux for Human Beings. [unhandled content-type:application/pgp-signature] |  |