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

On Sun, May 24, 2026 at 6:59 PM Paulo Fernando Barbosa Duarte
<[email protected]> wrote:
> 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.

So for what it's worth, I did have a plan for exposing the DTB to
userland in a somewhat similar way. We'd have a Mach device named
"dtb" (and perhaps a Hurd devnode at /dev/dtb) that you would be able
to map (via device_map) to get read-only access to the same DTB memory
region. Then userspace device drivers could read it to learn about the
system's configuration. We could even have a dtbfs translator that
would expose the device tree as a filesystem tree.

> > 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.

My advice would be, stop focusing on cpio so hard -- it's not standard
on AArch64 in any way, it's just the format used by Linux (on all
architectures). Try to get things booting with multiboot,module and
Mach bootscripts. The Mach/Hurd bootstrap process could use a revamp,
but that's a wholly separate task and it's not AArch64-specific, nor
about cpio.

Have you seen and/or built the wip-aarch64 glibc tree?

Then once you can reproduce what I had working (Hurd server bootstrap,
basic Unix, signals), focus on various interrupt and driver things. At
least get the PL011 driver that I had into a good shape, and hook it
up to Mach's console device, so you can actually get an interactive
shell. I got stuck in all the chario/tty layers that gnumach has
(apparently inherited from the BSD), but maybe you can power through
it.

Sergey