May 24, 2026 at 8:29 AM, "Sergey Bugaev" <[email protected] mailto:[email protected]?to=%22Sergey%20Bugaev%22%20%3Cbugaevc%40gmail.com%3E > wrote:
> > 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 +10,000 > > > > 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 >
