Al Boldi wrote:
The main issue -- which I am not sure what effect this patch has -- is
that we would really like to move initramfs initialization even earlier
in the kernel, so that it can include firmware loading for built-in
device drivers, for example.
I suspect, if there would be a problem with tmpfs, then ramfs would be no
different.
That is a very bold assumption (a.k.a. "just plain wrong".) ramfs and
tmpfs are a lot more different than one would normally think from a
kernel internals perspective.
Thus, if this patch makes it harder to push initramfs initialization
earlier, it's probably a bad thing.
Agreed, but remember that tmpfs is an option, not a replacement.
Red herring. If it goes in, it needs to be supportable going forward.
If not, the author of the patch
really needs to explain why it works and why it doesn't add new
dependencies to the initialization order.
Saying "this is a trivial patch" and pushing it on the -stable tree
doesn't inspire too much confidence, as initialization is subtle.
Ok, I did play with main.c, and as you mentioned, initialization is subtle.
But categorizing this patch as trivial is based more on the fact, that ramfs
and tmpfs are semantically equivalent, and as such should not impose
additional dependencies.
Again, that's just plain wrong.
-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]