[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Qoth Q3 2024 & on aarch64-gnu
From: |
jbranso |
Subject: |
Re: Qoth Q3 2024 & on aarch64-gnu |
Date: |
Tue, 24 Sep 2024 01:53:37 +0000 |
September 21, 2024 at 5:46 AM, "Sergey Bugaev" <bugaevc@gmail.com> wrote:
>
> 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
>
I'm game to try! How would I go about setting up a vm AArch64 image that
runs the Hurd? Do you have such an image? I should really create an
AArch64 page to document progress and how to help.
Samuel may we host a Hurd AArch64 image on debian's servers?
>
> 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 actually saw this in the irc log that made me ponder that porting
AArch64 is still quite an involved task:
<azert> I’ve read the email from solid_black. I remembered how I hoped to help
him with gnumach on arm64 \[16:23\]
<azert> Thing is that we made progress, but it felt a bit like finishing the
job would have required a total higher lever of effort, let’s say an
order of magnitude more \[16:24\]
>
> 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?)
>
I am sorry that you feel a lot of pressure on you to complete the AArch64
port. The last time I tried coding on the Hurd console...I got lost very
quickly, and I gave up just as fast. It was very kind of you to code
a Hurd crypt driver, and I honestly haven't reviewed that video yet. I
could sit down and try to understand libtrivfs with that video, even make
the Hurd documentation better with that. That would a great way for me to
help.
And I NEED to update the Hurd wiki's CSS, so that the wiki works on phones well.
I used to get paid to do that kind of work, and that task has been on my todo
list
for too long.
It would be pretty cool to run Debian GNU/Hurd on the MNT reform or a librem 5.
If we were to fundraise and hire some developers for a "complete" Debian
GNU/Hurd AArch64 port,
so that it would run on the MNT reform and/or a librem 5 and/or some other Open
hardware-y AArch64 device that I do not know of...how much would we need to
raise to pay for it? How many developers would we need to hire?
Would it be much cheaper for a complete Debian Hurd AArch64 that one would
run in qemu? It would be cool to start a bbuild box for AArch64.
I personally feel like creating a Hurd business would be a good idea.
That would be one way to pay for it. And/Or a Hurd foundation. I guess
the FSF would certainly be willing to help us fund raise. Guix did that once.
They used the FSF to fundraise the money, and the FSF kept 10%.
>
> 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.
>
What hardware board currently runs the Hurd?
It would be nice to document the device that runs the Hurd, for those
who want to try to test it and/or help.
>
> 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);
>
When I try to re-word things, typically people point out that my
re-wording them is somewhat incorrect. But when I quote things
verbatim, it's normally always right. I'll try to re-word it though
and see what happens this time, but technical things that you say
I'm going to try to avoid re-wording too much if that's ok.
>
> 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?
>
I hope so. I hadn't realized that they hadn't reviewed said patches. :(
>
> 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 :)
>
I'm game! What would you like to work on? If I'm being honest, I'll be
happy to attend, but I feel like I would slow you down. Or put it another
way...OpenBSD organizes developer hackathons. Only developers are invited.
They specifically do not allow enthusiasts to come, because those people
impede productive development hackathons.
If we were to organize a GNU/Hurd hackathon (which would be awesome), I
maybe would slow down the overall hackathon. I would need a lot of help,
setting up a development environment. I would ask lots of questions about
workflows. I really don't understand git super well or how to use it.
I have never submitted any code to the Hurd project. I haven't been
successful at porting any software to the Hurd. Netsurf is not packaged
for Debian Hurd, because I have given up trying to figure out to port it...
I should probably reach out to the developers and show them the little bit
of code that I have written. That would probably be a good idea.
>
> 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
It is cool thought that people can improve the Hurd's speed, with
minor code patches. That's awesome.
> would perhaps be more interesting to mention my (recently resumed)
>
>
>
> work on GHurdFileMonitor, which is a Hurd-native implementation of
>
>
>
> GLib's GFileMonitor.
What should I say about Glib's GfileMonitor?
> Sergey
Apologies for the weird formating on this email. My email client went weird on
me.
Re: Qoth Q3 2024 & on aarch64-gnu, Samuel Thibault, 2024/09/22
Re: Qoth Q3 2024 & on aarch64-gnu,
jbranso <=
Re: Qoth Q3 2024 (draft looking for comments) Installer Image..., jbranso, 2024/09/27