Olaf Hering wrote:
The other group is the one that uses some sort of initrd (loop mount or cpio),
created with tools from their distribution.
Again, they should install that kinit binary as well because kinit emulates
the loop mount handling of /initrd.image. This is for older distributions
that still create a loop mounted initrd.
There's no need for loop-mounting of any initrd.images. Initramfs (cpio image,
possible gzipped) works just fine, and it will NOT go away because something
should do the unpacking/loading of that image so that kinit &Co will run.
There's no need for old initrd+pivot_root at all. Only the ones who are,
for some reason, didn't switch to initramfs yet. And I personally see no
reasons not to switch - initramfs (rootfs) concept is much more clean and
easy to handle and gives more possibilities than initrd.
Are you saying that everyone now suddenly is forced to use a cpio image?
Why did hpa add the loop mount code to kinit?
So if you force people who build kernels to use newer tools, one more
external binary will surely not hurt.
When you say "loop mount code" I presume you mean legacy initrd support
(which doesn't use loop mounting.) Legacy initrd support is provided to
be as compatible as possible, obviously.
And yes, it should be a configurable. Chopping kinit into configurable
pieces is on my short list.
-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]
