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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.