Re: [PATCH v2] initramfs: Support unpacking directly to tmpfs

[Emily Shepherd <emily@redcoat.dev>]

On Fri, Dec 01, 2023 at 11:40:37PM -0600, Rob Landley wrote:
>No, "the perfect is the enemy of the good" applies. Blocking a small 
>fix to
>force a large fix isn't always reasonable.
>
>I just dislike adding special cases. Right now when you root=/dev/sda1 you
>specify what to overmount on rootfs at runtime, so if you're going to overmount
>something _else_ that seems the layer to do it at. A CONFIG_BLAH=y option to do
>a similar thing (changing the semantics from a different area entirely) seems
>painful, especially as a workaround for a self-inflicted issue in a userspace
>package.

Understood.

>At least until the network admin running kernel.org gets his way and closes down
>the open mailing list, replaced by one that only approved people are allowed to
>join:
>
>https://social.kernel.org/objects/9b3adb80-4198-4c86-abbd-aa3c58700975

Haha wow, I have to say: reading the LKML discussion about this is so 
surreal. Lots of people are suggesting features that have been standard 
in all of the git hosting platforms for years like they are new. I 
really don't understand the reluctance to move to one of the existing 
platforms. Most support outputting plaintext patches, or raising / 
responding to patches via email for people who like that flow. Seems 
like a win win, as it would come with all the extra patch / pull request 
management for free.

>I'm weird enough to still _try_. At least in the parts common to the 
>systems I'm
>building on a dozen different architectures. (_Everybody_ has to go through
>early boot.)

Fair point :)

>I'm currently trying to get vanilla u-boot, linux, and devuan 
>debootstrap to run
>on the orange pi 3b.

Nice. My current project started life on the raspberry pi :) I wanted to 
run containers, but quickly became frustrated at all the extra stuff 
that Raspberry Pi OS was running, which was slowing everything down for 
no reason, so I went on a crusade to make a much more minimal system - 
it looks like there were actually some similarities with mkroot! Great 
minds think alike, I suppose :) Anyway, I have now moved over to support 
amd64 too as I realised what I'd built could boot to kubernetes faster 
than AWS' tailored images can, so looking at options there.

>(Unlike raspberry pi which is still
>binary blobs as far as the bootloader can see and a forked kernel.)

Gah, the weird binary blobs really, really bug me on the RPI. Not least 
because the whole point of the Pis was meant to be a learning / 
exploration tool, so having a "just trust me bro" blackbox of a 
bootloader is so absurd.

>The change under discussion here is a case where explaining the design context
>behind this distinction, let alone the decision to change it, is multiple
>minutes for a domain expert to unpack the backstory for you, and hours if not
>days to pick apart yourself. It changes what the design IS. I personally already
>_know_ (some of?) the backstory, but I don't expect other people to, and really
>don't look forward to having to document it.

It looks like this patch isn't going to go anywhere - I'll keep it in my 
own tree for the moment, as it is useful for me, but may play around 
with the CLONE_NEWROOTFS idea if I have time - certainly would be 
interesting to see how easy it would be create proper independent mount 
namespaces (cue: something random falling over!).

-- 
Emily Shepherd

Red Coat Development Limited