Re: [RFC PATCH 03/18] aarch64: drop the ramdisk driver from the import

Sun, 24 May 2026 08:59:44 -0700 


> On 24 May 2026, at 13:49, Sergey Bugaev <[email protected]> wrote:
> 
> This is not my code at all, the patch was taken from Debian, authored
> by Jérémie Koenig <[email protected]> [0]. Nor is it AArch64-specific.
> 
> [0]: 
> https://salsa.debian.org/hurd-team/gnumach/-/blob/master/debian/patches/50_initrd.patch
> 
Thanks for letting me know, will make sure to credit it properly on v2

>> It's
>> declared in aarch64/aarch64/conf.c's dev_name_list[] via the
>> RAMDISK_DEV_OPS macro and no other in-kernel consumer touches it;
>> the apparent intent (per the original commit context) was to use
>> it as a transport for boot modules embedded in the DTB. That
>> transport never landed — wip-aarch64 settled on
>> /chosen/multiboot,module DTB nodes via QEMU's guest-loader
>> instead, leaving ramdisk half-wired:
> 
> ??? One does not replace the other. /chosen/multiboot,module DT nodes
> is how a *bootloader* passes the info about a memory region that
> contains the payload of a boot module (in the user case for a ramdisk,
> a file system image). ramdisk is the mechanism that Mach then uses to
> expose such a memory region to userland, activated by the
> ramdisk-create boot script command.
> 
I confess I got a bit lost that one at first, and I ended up getting the wrong
Reasoning, I thought at first the ramdisk was used to store the DTB.

> The reason we want something like a ramdisk is the same as why initrds
> are used on Linux: the bootloader loads some small chunk of data into
> RAM (or perhaps it's hard-wired ROM, or something), and the OS being
> booted can then mount the contents of the ramdisk as a filesystem
> image and run some userland code off of it, before it bootstraps
> enough functionality to use its own storage drivers (or unlock the
> root filesystem if it's encrypted etc). In case of AArch64 GNU Mach,
> this need is exaggerated by the fact that we had no usable storage
> driver at all, so we just could not use a real disk or some flash
> memory; ramdisk was the only "storage" one could run a system from.
> 
I totally agree with you that we need the ramdisk for the userland, this
Removal will definitely go away in v2

> Did you get GNU/Hurd on AArch64 to run without ramdisk, by using some
> other form of storage, somehow?
> 
I didn’t get even close yet, long roadmap to get there.

> For what it's worth, I did not like ramdisk's specifics, because it
> copies out data to the kmalloc heap, which is limited in size, and
> IIRC the data stays on there forever, even once the system no longer
> needs it. My idea was a different way that Mach could expose this, VM
> objects [1]. The userland would then use libstore's vmobj backend,
> instead of its device backend, and the memory would be properly freed
> once the port reference is deallocated.
> 
> [1]: https://lists.gnu.org/r/bug-hurd/2023-08/msg00097.html
> 
I will look into memory mapping an uncompressed CPIO just to get
the core startup userland and their RPC params, boot_script
this may cleanup the process a little bit, but have to experiment
first.

Paulo

























					Reply via email to