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
