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

[Jeff Bailey <jbailey@ubuntu.com>]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

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.

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 191 bytes --]