Received-SPF: pass (google.com: domain of linux-kernel+bounces-16939-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <c7b8d248-fb59-0476-dea8-89d40207460f@landley.net>
Date: Thu, 4 Jan 2024 10:38:53 -0600
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is
 given
Content-Language: en-US
To: Askar Safin <safinaskar@gmail.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>, gregkh@linuxfoundation.org,
 initramfs@vger.kernel.org, linux-kernel@vger.kernel.org,
 stable@vger.kernel.org, zohar@linux.ibm.com
References: <CAPnZJGDcNwPLbzC99qNQ+bRMwxPU-Z0xe=TD6DWQU=0MNyeftA@mail.gmail.com>
 <d4b227de-d609-aef2-888b-203dbcf06707@landley.net>
 <CAPnZJGBeV-E_AN8GnTfkaJvRtBmCeMYYCt+O0XMsc3kDULRuKg@mail.gmail.com>
 <fb776d99-1956-4e1b-9afc-84f27ca40f46@linux.ibm.com>
 <0879141d-462c-7e94-7c87-7a5b5422b8ed@landley.net>
 <e32077de-b159-4a7b-89a3-e1925239142f@linux.ibm.com>
 <fcb45898-0699-878f-0656-f570607fbed4@landley.net>
 <CAPnZJGAr8BfTHmn3QZnJ6dnVCQsUnUASmdH4tzz0-QMwHmZZLQ@mail.gmail.com>
From: Rob Landley <rob@landley.net>
In-Reply-To: <CAPnZJGAr8BfTHmn3QZnJ6dnVCQsUnUASmdH4tzz0-QMwHmZZLQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 1/4/24 00:06, Askar Safin wrote:
> On Sat, Dec 30, 2023 at 8:01 PM Rob Landley <rob@landley.net> 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