[klibc] Query regarding initramfs

[Eric W. Biederman]

"H. Peter Anvin" <hpa at zytor.com> writes:

> Milton Miller wrote:
> > With the current code there is no reason initramfs pieces have to
> > be linked into the kernel.   Instead the pieces can be loaded into
> > memory by the bootloader and passed to the kernel as an initrd.  As
> > of early January, the pieces can have empty (zeroed) space between
> > them.  The linking mentioned above is a historical reference.
>  >
> 
> Well, you *can* link it into the kernel; in fact, the initramfs can come from
> *both* sources!
> 
> This is a good thing; it's not currently used that much, but will soon.
> 
> > Using initramfs means that one does not have to rebuild a filesystem
> > and replace the old image on the boot media to add a driver or similar.
> > I can see this as a feature for installers.
> > However, as I mentioned one needs to be aware of the limitations
> > of rootfs.  It is a ramfs, not tmpfs that could fall out into swap.
> > Each symlink takes a page.  It can't be unmounted to free space,
> > instead the files must be removed.  Also, the unpatched kernel
> > returns the max size as the current size, which may cause package
> > installers to abort.
> 
> Note that it's a pretty trivial patch to the kernel to change rootfs to a tmpfs
> instead of a ramfs.  In fact, the main reason that hasn't been mainstreamed is
> because "noone has asked for it."

Would that give mountfs mount --bind support?

Last I looked that wasn't there and it gave udev coniption fits.

As for ramfs vs tmpfs a tmpfs option is nice but I think some users without swapspace
would be annoyed if they had to use a tmpfs.

Eric