> On 24 May 2026, at 13:29, Sergey Bugaev <[email protected]> wrote:
>
> but I cannot be thought of as any sort of expert on
> either AArch64 or Mach at this time.
>
Neither do I, trying my best to get my head around.
> 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
>
I would feel great to have sparked you return to this.
> 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.
>
Yes, I don’t have the full picture on how to solve that yet, Its a long way
until I can have a proper userland running. But one idea I to have a basic
CPIO (uncompressed) to pass the initial userland and scripts
> 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.
I’ll be happy when I have some data sent via UART from the device, but
even that is still far.
> 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.
>
Yes I know, I intend to peek into some of the Assahi drivers maybe
to get the very basic working.
>> 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.
>
I think it’s important to disclose this, it’s a very polemic subject these
days, I used it mostly for helping with research and discovery of the
codebase and boring tasks like helping me set some sane building
system
> 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.
That’s my rationale as well, want comments to see if I am in the right
path. But I think it needs to better broke down before merging upstream,
Paulo
