[klibc] New to this list, and a first question

[H. Peter Anvin]

Harald Dunkel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> H. Peter Anvin wrote:
> | Harald Dunkel wrote:
> |
> |> skeleton for NFS mount, etc.). On a kernel update
> |> all you have to do is to select the right skeleton
> |> for your boot method, append some new kernel modules
> |> to this cpio file, and you are done.
> |>
> |
> | That's exactly what you *DON'T* want, because it makes it nearly
> | impossible to migrate kernel functionality to userspace.  Instead you
> | want the kernel to be able to couple some functionality tightly, while
> | having a well-defined interface for augmenting that functionality.
> |
> |     -hpa
> |
> 
> I am not talking about the migration to initramfs support
> (i.e. the development process going on at the moment),
> but about the "final" state.
> 
> A distro maker wouldn't be interested in an initramfs
> "migration" going on upstream. All he wants is a working
> snapshot for his next release.
> 
> Lets say he has selected kernel 2.6.42 for his release,
> naming it 2.6.42-1. Of course he would like to release
> kernel updates 2.6.42-2, 2.6.42-3 and so on without
> having to rebuild the initramfs from scratch on the user's
> machine for every new patch.
> 

You're missing one of the main points of initramfs: unlike initrd, it's 
modular.  The kernel image can contain one piece, and the distro can 
have another component loaded via initrd protocol.  In fact, each of 
these can be modular.

	-hpa