On 1/4/24 00:06, Askar Safin wrote: > On Sat, Dec 30, 2023 at 8:01 PM Rob Landley <rob@xxxxxxxxxxx> wrote: >> I've been following the initramfs xattr support threads forever: > > Here is my proposal: add to the kernel support for catar ( > https://0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html > ) in addition to cpio. catar has the following advantages: Didn't we just have a thread about the inadvisability of adding more ways to do the same thing, with each existing codepath still having to be supported forever? And your solution is a link to the website of Lenart Pottering, author and maintainer of systemd. You want to put systemd code into the kernel. > - catar is simple and reproducible. For the same directory tree the > same bit-precise catar file is generated, which is good for > cryptographic signatures. I can trivially reproduce the same cpio each time from the same tree, the trick is just fetching the whole directory and sorting it before processing (to squelch hash-impacted readdir() return order from the filesystem). > As opposed to tar's monstrosity ( > https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar ) > - catar has support for xattr. Adding xattr support to my toybox cpio implementation is maybe 10 lines of C, I assume the other implementations aren't that much more tangled. The question was always a largely aesthetic issue of file format. Tar is NOT well-defined. I say this as someone who has IMPLEMENTED tar and has a pending TODO item to patch up YET ANOTHER funky corner case du jour somebody hit: https://github.com/landley/toybox/issues/469 Inventing a NEW file format... there are multiple dozens already: zip, arj, lharc, zoo... You could theoretically extract squashfs into initramfs because technically it's an archive format. Good grief, there's an xkcd on that: https://xkcd.com/927/ > It has support for nearly all types of "nearly" Please no. > metainformation Linux offers (32 bit UIDs, nanosecond timestamps, > "disable CoW" flag and various other flags, selinux file labels, file > capabilities, etc). All this metainformation can be disabled if > needed. So, next time we will want to add some new type of > metainformation, there will be no need for lengthy discussions about > how it should be stored. There's no real need NOW. "We did not come to an agreement in email" does not mean "let's add a new unrelated format". It means let's carve out an hour to actually speak to each other, by voice and maybe video, using this thing called the internet. (Without covid we'd have had a BOF at some conference by now.) Rob
