On Sun, May 24, 2026 at 4:43 AM Paulo Duarte <[email protected]> wrote:
>
> Hello Samuel,
>
> This series adds the gnumach kernel-side implementation for the
> aarch64 ABI Sergey landed in April 2024, plus the test-suite arms.
> Patch 01 brings in the aarch64-only sources from bugaevc/wip-aarch64
> verbatim, with Sergey as Author; the rest is mine.
Hello, and, wow!
I'll admit upfront that in the few years that have passed since I was
involved in this, my memory and domain knowledge have -- naturally --
largely faded. I might remember some things, and perhaps give some
useful feedback, but I cannot be thought of as any sort of expert on
either AArch64 or Mach at this time.
This might be a great excuse/opportunity to get back into Hurd hacking
for me though, which is something that I very much want to do. Anybody
miss me? :D
> The meaningful divergence from wip-aarch64 is what I left out:
> roughly 150 files of cross-arch refactoring across kern/, ipc/, vm/,
> device/intr.{c,h}, and the i386 tree. Each got replaced with a
> smaller per-arch shim under aarch64/ so kern/bootstrap.c,
> device/intr.{c,h}, kern/lock.h, and the i386 trees all stay
> bit-identical to current master. The shared-file footprint outside
> aarch64/ is four files: a new ELF constant, two missing decls plus
> their include, and a linker-symbol filter extension.
So, yes, the hacked-together integration points with the rest of Mach
in places such as the bootscript/multiboot were one of the remaining
TODOs, IIRC.
> The bootstrap reader handles two DTB conventions:
> /chosen/multiboot,module (Sergey's, multi-module, fed by u-boot's
> `fdt mknod` per aarch64/BOOTING) and the standard arm64
> /chosen/linux,initrd-* so any stock bootloader works. Tests use the
> multiboot,module path; linux,initrd runs but QEMU's `-initrd`
> placement bumps into the single-segment vm_page heap. A
> multi-segment heap is on my follow-up list.
But /chosen/linux,initrd-{start,end} only lets one provide a single
module ("initrd"), and no way to pass arguments to the module, right?
How would you boot a userland out of this? Even if you limit yourself
to a single boot module (which is not going to suffice for the Hurd,
but might for simple tests), you need to pass special ports like the
host-priv and device master ports to it.
> Patches 11 and 12 each bundle two fixes that surfaced together when
> I first delivered a bootstrap module end-to-end and ran
> tests/test-thread-state-fp. I haven't reproduced them against
> wip-aarch64 directly (at least the kvtophys-contract half of patch
> 11 plausibly belongs to this series' integration with upstream's
> bootstrap.c rather than the imported code), but the fixes are needed
> either way. Splits are recoverable if anyone would rather review
> them separately.
>
> Tested: 12/12 pass on x86_64, i686, and aarch64 under qemu. No
> bare-metal validation yet. I plan to build bootable images and boot
> the kernel on Apple M1 / Raspberry Pi (aarch64) and an x86_64 box
> (x86_64 + i686). Help on any of these welcome.
To get something running on any of those hardwares, you would need
drivers for at least things like the interrupt controller, the serial
console, and the timer. IIRC, Raspberry Pi has something rather
specific, and Apple M1 does not even use GIC, they have their own AIC.
This is/was also the largest missing piece for this whole AArch64
effort: drivers! And specifically, someone who has an idea of how to
design non-trivial interrupt handling frameworks, so we could handle
several interrupt controllers being stacked. I had a stab at it with
the irq_ctlr stuff, but really, someone who knows what they're doing
needs to take this into their hands and make all the interrupts and
in-kernel drivers work.
> I used substantial AI assistance (Claude Code) on this. Every line is
> mine and the FSF assignment is on its way. Disclosing in the cover
> rather than per-commit since bug-hurd has no precedent either way;
Ack, good on you for disclosing this upfront.
You must realize that using AI of course makes people take this work
with a grain of salt (or, more like, a pound of salt). But on the
other hand, I had no idea what I was doing at the time, and I have
even less now, only a faulty memory of something I haven't been doing
for a few years. So your understanding might be better than mine is :)
Generally, I think it makes sense to review this work as a diff on top
of my branch, but it would make a lot less sense to apply it upstream
this way. So if your intention is to get this eventually merged, I
would advise that after a few rounds of review you squash the changes
and instead split the work into patches adding various subsystems on
top of the upstream tree.
Sergey
