[klibc] klibc-1.5 released

[H. Peter Anvin]

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'm trying to find things where klibc easily extends the capabilities 
beyond the stock kernel, without having the embedded people balk.

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

>> - 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"?

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

	-hpa