On Sun, May 24, 2026 at 4:43 AM Paulo Duarte <[email protected]> wrote: > > device/ramdisk.{c,h} from bugaevc/wip-aarch64 implements a Mach > device driver that exposes a RAM-backed block device.
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 > 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. 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. Did you get GNU/Hurd on AArch64 to run without ramdisk, by using some other form of storage, somehow? 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 > Rationale: a RAM-backed block device is userland territory in > Mach's microkernel design. Hurd's `storeio` translator covers > the same role from the userland side — Mach exposes the raw > memory via the device port, Hurd layers the block-device > abstraction in userland where the rest of the storage stack > lives. Pulling a new in-kernel device into the port without a > concrete consumer also goes against the minimum-touch principle > the rest of this series follows. > > This is the only change to a Bugaev-authored file in this series > made for architectural reasons rather than build/runtime > correctness. If reviewers (notably Sergey Bugaev, who authored > the original ramdisk driver) want it kept and wired in, this > commit is straightforward to revert; nothing later in the series > depends on its absence. It was not itself a part of the AArch64 work, it was there in my tree for convenience, because you want it to be there to actually run a GNU/Hurd userland. Sergey
