Gerd Hoffmann wrote:
Hi,
As it looks like it's distribution which are mostly interested in this.
Have you talked with any distribution maintainer to find out what they
need and what they want to put initramfs? What are the exact problems
which distributions have and how do you want to solve them?
Well, we already have an initramfs, and it can do quite some stuff the
current kernel doesn't do. Here is a (probably incomplete) list:
* load kernel modules needed to access and mount the root filesystem
(block device driver, filesystem module, device mapper, ...)
* raid/lvm2/evms setup.
* iscsi setup.
* fsck root filesystem before mounting it.
* setup /dev in tmpfs (using udev).
How do we avoid having to split all utils into a klibc version and the
normal version?
That is a big question. Latest suse doesn't use klibc any more. Older
versions had a bunch of static klibc-based binaries for some utilities,
i.e. insmod, udev, sh. Sometimes you needed glibc because one of the
tools needed in initramfs had no klibc-version (rootfs-on-lvm case for
example). After adding the "fsck rootfs" feature (I think) we had glibc
on the initramfs in almost all cases. So if you end up with glibc in
initramfs anyway, what is the point of having klibc?
For a "big" distribution that runs on modern kernels, then by all means,
build something around glibc. The additional disk space and memory is a
proverbial drop in the bucket.
However, I don't think it's realistic for smaller systems.
One advantage of merging klibc as-is is that it becomes much more
visible and receives more testing. And it is probably easier to make
utility maintainers support building with klibc then (instead of forking
a klibc version of every utility). That still leaves some maintaining
questions though, because we likely end up with some utilities coming
bundled with the kernel (sh, nfsmount, kinit, ...) and some not (lvm2, ...).
The stuff that's bundled with the kernel are replacements for kernel
functionality. The purpose of bundling is that kernel functionality can
be removed. Obviously, utility developers can build with klibc; this is
already supported by several out-of-tree utilities, including udev.
Should udev be bundled with the kernel? It could be debated; however,
it doesn't really affect the situation at hand.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
