Re: [RFC PATCH 00/23] aarch64-gnu port

[Sergey Bugaev <bugaevc@gmail.com>]

On Wed, Jan 3, 2024 at 8:30 PM Joseph Myers <jsm@polyomino.org.uk> wrote:
> I think the same principle applies for ports to new (architecture, Hurd)
> pairs as for new (architecture, Linux) pairs: the relevant code needs to
> be in upstream mainline of all components on which glibc build-depends
> before the port can go into glibc (and thus before the symbol versions for
> the port can be determined) - and at the point where it's ready to go in,
> a corresponding build-many-glibcs.py entry should be added as part of the
> patch series.  Parts of <https://sourceware.org/glibc/wiki/NewPorts> may
> be applicable, though that's more oriented to the case where the
> architecture support itself is entirely new.
>
> You can of course do refactors of existing files not specific to
> aarch64-gnu, in preparation for the port, before then, to reduce the size
> of the eventual patch series proposing adding the port to glibc.

Certainly; and I should've been more clear about this: I don't expect
this to get merged until there's a gnumach port. And the port
development, and the feedback I'm hoping to get, will likely require
changes/tweaks to the Mach headers/APIs (as I've said, my versions
I've developed this against are more like preliminary sketches than
final APIs set in stone) and the corresponding changes to this port,
so I don't expect it to be merged until that all is settled.

Some generic improvements could be merged now as you're saying, but
other than that, I'm posting these patches both to gather feedback
from both Hurd and glibc communities, and to enable others to build
it, experiment with it, and build more stuff on top of it (for
example, can we get all of the Hurd building?). Symbol versions, I
have set to 2.39, but seeing how the 2.39 release is already in
progress, we'll likely need to bump this.

Sergey