![]() | |||||||||||||
Messages in this thread |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-07-31 21:27 [from the cache] ©2003-2008 | |||||||||||||