On 5/17/19 4:41 PM, H. Peter Anvin wrote: > On 5/17/19 1:18 PM, h...@zytor.com wrote: >> >> Ok... I just realized this does not work for a modular initramfs, composed >> at load time from multiple files, which is a very real problem. Should be >> easy enough to deal with: instead of one large file, use one companion file >> per source file, perhaps something like filename..xattrs (suggesting double >> dots to make it less likely to conflict with a "real" file.) No leading dot, >> as it makes it more likely that archivers will sort them before the file >> proper. >> >> A side benefit is that the format can be simpler as there is no need to >> encode the filename. >> >> A technically cleaner solution still, but which would need archiver >> modifications, would be to encode the xattrs as an optionally nameless file >> (just an empty string) with a new file mode value, immediately following the >> original file. The advantage there is that the archiver itself could support >> xattrs and other extended metadata (which has been requested elsewhere); the >> disadvantage obviously is that that it requires new support in the archiver. >> However, at least it ought to be simpler since it is still a higher protocol >> level than the cpio archive itself. >> >> There's already one special case in cpio, which is the "!!!TRAILER!!!" >> filename; although I don't think it is part of the formal spec, to the >> extent there is one, I would expect that in practice it is always encoded >> with a mode of 0, which incidentally could be used to unbreak the case where >> such a filename actually exists. So one way to support such extended >> metadata would be to set mode to 0 and use the filename to encode the type >> of metadata. I wonder how existing GNU or BSD cpio (the BSD one is better >> maintained these days) would deal with reading such a file; it would at >> least not be a regression if it just read it still, possibly with warnings. >> It could also be possible to use bits 17:16 in the mode, which are >> traditionally always zero (mode_t being 16 bits), but I believe are present >> in most or all of the cpio formats for historical reasons. It might be >> accepted better by existing implementations to use one of these high bits >> combined with S_IFREG, I dont know. > > > Correction: it's just !!!TRAILER!!!.
We documented it as "TRAILER!!!" without leading !!!, and that its purpose is to flush hardlinks: https://www.kernel.org/doc/Documentation/early-userspace/buffer-format.txt That's what toybox cpio has been producing. Kernel consumes it just fine. Just checked busybox cpio and that's what they're producing as well... Rob
