bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Qoth Q3 2024 & on aarch64-gnu


From: Sergey Bugaev
Subject: Re: Qoth Q3 2024 & on aarch64-gnu
Date: Sat, 21 Sep 2024 12:46:03 +0300

On Fri, Sep 20, 2024 at 4:45 PM <jbranso@dismail.de> wrote:
> Hey Hurd friends!

Hi,

> Sergey I didn't see any new code relating to AArch64, but I think you had 
> said that you have the Hurd running on real hardware? What hardware? Would 
> you like me to add a paragraph on how "stable" the Hurd is on AArch64?

there hasn't really been any new developments in aarch64-gnu land.
This is not necessarily bad, it just means I've been focusing on other
things, both in hacking (I spent a lot of time making this very cool
GTK & C++ -related project, born out of frustration with gtkmm), and
on improving my real life & mental health.

As for the future of Hurd on AArch64, this is actually something that
I wanted to ask *you* (Josh) to help me with. See, I get this
impression that other people's idea of aarch64-gnu is "we just have to
wait until Sergey makes it happen"; but this is so not true, and only
leads to frustration (mine, and everybody else's when they see no
progress being made). This is because I certainly cannot do it all by
myself; and the parts that I could do myself, I have done already — in
fact, I've done more than I thought I could.

I know some stuff about Mach and Hurd and Unix and AArch64, but I only
know so much, and I also know very well where my knowledge &
experience ends: things that are close to the metal (or, well,
silicon?), so various hardware things, including device drivers. On
the other hand, there are people, both within our Hurd community and
outside of it, who seem to feel right at home juggling complex
questions about hardware & device drivers, and yet feel less
comfortable around Unix and Mach concepts, ones that seem
straightforward to me. (And then of course we are very lucky to have
Samuel, who is seemingly an expert in just about everything :D)

So it's just not realistic to expect me, working alone, to produce a
full Mach/Hurd system running on real AArch64 hardware. Does that mean
that I have bitten off more than I can chew? Yes and no. Yes, because
I "came up" with aarch64-gnu without coordinating it with anyone, not
even running the idea by Samuel first. No, because I never promised or
expected to do a full port by myself. I started hacking on the glibc
port without even fully expecting to get that done, it was a "let's
see what breaks and how far I can take this" project. And that was
because I felt somewhat confident around glibc internals, so I kind of
knew I could at least try to do it. I was hoping someone else would
get inspired and do the Mach port, including all the hardware-y parts.

It was Luca who kind of stepped up to hack on Mach on AArch64, but he
didn't get very far. So I started hacking on it myself (with Luca's
occasional help), as another "I have no idea what I'm doing, but let's
see how far I can take it nevertheless" project. And amazingly enough,
it went quite far, from running some early Mach initialization code
before crashing, to fully initializing itself, to running a few
instructions in EL0 (userland), to running a userland hello world, to
passing Luca's self-tests, to running my glibc hello world from
earlier, to booting enough of Hurd to have a Unix environment.

Amazing as it is, still, I cannot, and cannot be expected to, complete
all the hardware- and driver things, to make it full and usable. For
aarch64-gnu to succeed, we'd need people who are proficient,
experienced, comfortable with hardware & drivers (not at all
necessarily ARM-specific, I'm sure the skills and intuition translate
well from x86) to join in & hack on it. We need drivers, many of them.
We need a proper interrupt handling framework / interrupt controller
support. (For instance, I saw Jessica Clarke's name while trying to
read through FreeBSD's interrupt handling framework; perhaps Jess
would be interested in hacking on this? or sharing some pointers for
others?)

As a positive example, back in spring, azert of IRC stepped in to
help, got things building & running, first on QEMU, and then indeed on
a real hardware board; we fixed several issues in AArch64 gnumach in
the process.

You excel at communicating with & organizing the community, so please
spread the word and get people to understand this situation (but also
please don't quote things from this message verbatim, use your own
words); see if we can get anyone interested in hacking on the hardware
side of Mach & Hurd on AArch64. Then maybe we could make some
progress.

On the other side of this, from a chat that I had at one point with
Samuel, I understood that basically once glibc patches are merged, he
could cross-build lots of Debian packages for aarch64-gnu, which would
of course be awesome. Getting those patches merged involves, for one
thing, me posting a rebased & slightly updated version, but also glibc
maintainers reviewing them — and it's been months since I posted the
v2 patches, and they still haven't. Hopefully they'll regain interest
if I post a v3?

Also: let's schedule another hacking call some time, like the one we
did last time? But maybe with some more productive hacking and some
less pressure on me :)

> Samuel is ok with using rust code in the Hurd code base. If you have an idea 
> for a Hurd translator that you want to write in rust, then get in touch!

That's not quite how it works. To write a translator in Rust, you need
there to be a translator framework being available in Rust. You could
either make Rust bindings for the existing Hurd libraries/frameworks
(libports, libpager, libnetfs...), or write a new one from scratch.
Since Rust doesn't really like the "network of objects in heap memory
all pointing to each other" style of memory management, the former
approach will result in some awkward, unidiomatic code. The latter
approach sounds more promising, especially since things could be
integrated with Rust's native async/await syntax (which C lacks), to
enable multiplexing incoming requests over a small pool of threads
like web backends do. However, it's unclear if/how this should
integrate with MIG; we might have to write another version of MIG
which would generate Rust- and async/await-native stubs, but also this
is suboptimal because MIG is obscure enough as it is, it would be a
shame to essentially fork it.

> Sergey Bugaev sped up access () / faccessat (), when checking for file 
> existence. This is prompted by GLib switching to use faccessat (F_OK) to 
> implement g_file_query_exists () for local files.

Not sure if this is worth mentioning, since it's really minor. It
would perhaps be more interesting to mention my (recently resumed)
work on GHurdFileMonitor, which is a Hurd-native implementation of
GLib's GFileMonitor.

Sergey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]