Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description
On Fri, 26 Jan 2018, Victor Kamensky wrote: > On Fri, 26 Jan 2018, Henrique de Moraes Holschuh wrote: > > On Thu, 25 Jan 2018, Rob Landley wrote: > > > That said, I don't think -h newcx should emit (or recognize) the > > > "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018: > > > files have a length, pipes provide EOF, and each cpiox entry starts with > > > 6 bytes of c_magic anyway. > > My understanding that TRAILER is really used on tape devices, > there is no notion of file end in this case, it is just a stream of bytes > from char device. TRAILER is really used anywhere you can have several cpio archives concatenated, which is the exact case of a Linux initramfs, not just tape. The initramfs format takes *one or more* cpio archives, concatenated. Each archive may be independently compressed (using whatever supported compression method), or uncompressed[1]. EOF or size information can only tell you where the entire concatenated archive ends, not where each "segment" (independent cpio archive that was concatenated into the whole) ends. TRAILER is the only decent way to know the concatenation points. Knowing where these points are is necessary for the kernel, due to the way hardlink encoding is done on cpio archives: one has to reset the state of the hardlink-tracking table between cpio archives that were concatenated, for safety (and sysadmin sanity) reasons. [1] for the special case when one includes an "early initramfs" section for firmware (microcode, etc) updates, the archive(s) containing the firmware data must be uncompressed, and these archives must come before compressed archives in the concatenation. -- Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description
On Thu, 25 Jan 2018, Rob Landley wrote: > That said, I don't think -h newcx should emit (or recognize) the > "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018: > files have a length, pipes provide EOF, and each cpiox entry starts with > 6 bytes of c_magic anyway. (I stopped toybox from producing the TRAILER > entry back in june, toybox commit 32550751997d, and the kernel consumes > the resulting cpio just fine. All the trailer does is prevent you from > concatenating cpio files, which is a feature multiple people asked me for.) Not in the kernel. What TRAILER does in the kernel is to act as a barrier for the hardlink creation state, which IS a good thing. You could just specify it as such for "newcx". The kernel will continue reading for more entries after TRAILER, so concatenation is not broken by TRAILER. It is also insensitive to NUL-padding length (as long as it is 4-byte aligned), which is another nice feature you could specify for "newcx". Also, the kernel does something nothing in userspace ever tried to, AFAIK: it detects compression signatures along with the CPIO header signatures, and thus it can take several compressed and uncompressed archives concatenater together (and the compressor doesn't need to be the same, either). -- Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add kernel parameter to blacklist modules
On Tue, 14 Jun 2016, Christoph Hellwig wrote: > On Mon, Jun 13, 2016 at 08:32:41AM -0400, Prarit Bhargava wrote: > > Blacklisting a module in linux has long been a problem. The process of > > blacklisting a module has changed over time, and it seems that every OS > > does it slightly differently and depends on the age of the init system > > used on that OS. > > And why would we care about blacklisting a module? Because the "Current Best Practice" way to help users blacklist modules that won't drag you to nasty places trying to ensure they did it right (i.e. "mv" the .ko file away then trigger an initramfs update and reboot) just covers situations where the system actually boots/installs mostly fine in the first place. So, yes, such a feature looks like it would be rather useful, to the point that I'd even advocate for it to be backported (once it has been in a released mainline kernel for a while to remove any risk of regressions, of course). And if such a module blacklist feature ends up being invoked by the "nuke_module_from_orbit=" parameter, I will pay the author (and the subsystem maintainer that manages to get that merged) a couple beers should we ever meet in real life :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
