[klibc] klibc-1.5 released

[David Härdeman]

On Tue, Mar 06, 2007 at 08:43:02AM -0800, H. Peter Anvin wrote:
>David Härdeman wrote:
>>hpa at zytor.com wrote:
>>>I'm looking at the following:
>>>
>>>- Mount-by-label/mount-by-uuid.
>>
>>The Debian/Ubuntu initramfs-tools package integrates udev and uses the
>>/dev/disk/by-*/something symlinks for the mount-by-label and mount-by-uuid
>>support.
>>
>>The advantage is that it works with all kinds of tools that are used to
>>bring up the root dev (think lvm, evms, cryptsetup, raid, etc) without
>>having to change each and every one of them to understand labels/uuid's.
>>
>>In addition, it means that the fs/label/uuid/size detection is centralized
>>in libvolumeid (from udev).
>>
>
>As much as I like this concept, I don't really think the kernel 
>community is going to even consider all that stuff being integrated into 
>the kernel tree... at least not right off the bat.

I was not suggesting that udev be integrated in it's entirety. But 
rather that if mount-by-label/mount-by-uuid is to be integrated, 
functionality to parse uuid's/labels is needed and libvolumeid might be 
a good candidate which would at the same time allow fstype to be 
removed.

>I'm trying to find things where klibc easily extends the capabilities 
>beyond the stock kernel, without having the embedded people balk.

Understood...I assume this is in order to have a selling point for 
getting klibc into the kernel?

Isn't the initramfs shell one such argument? Getting a shell on boot 
failure is a major improvement over a panic message...

>I could be wrong about that, though, especially if someone other than me 
>drives the issue.  It would definitely have to be configurable, though.

Of course, but that sort of goes for any additions which go beyond the 
trivial I'd assume...

>>>- Ability to fall back on different roots.
>>
>>Meaning? That several root= parameters could be passed to the kernel and
>>they would be tried in order? Or something more advanced?
>
>The former, unless you have something specific in mind for "more advanced"?

Not really, but one thing to consider might be "root-wait", that is, if 
the rootdev is missing, instead of putting up a panic message, kinit 
could hang around for a while and see if the root device shows up (think 
slow scsi/usb/firewire scanning here...or root on a usb-key or 
something). We're discussing something like that for Debian's initramfs 
right now (the current idea is to add a rootdelay=<some device or 
number of seconds> parameter).

>>>- nfsroot on NFSv4.
>>>- nfsroot over IPv6, as soon as the kernel supports NFS over IPv6.
>>
>>Sounds interesting, but wouldn't a proper NFSv4 support require quite a
>>large crypto infrastructure?
>
>As does "proper" NFSv3 (you can do NFSv3 over secure RPC, although very 
>few people do.)  That doesn't mean we have to support nfsroot over every 
>possible option.

Yes, but NFSv4 mandates some security features, doesn't it?

-- 
David Härdeman