I'm talking about Fidora Sahi, which is Fidora for Apple Silicon.
It's funny.
I was in the bar the other night talking with David and Neil about doing this presentation.
And I said, yeah, on that Mac Mini, on about one in ten displays, it just doesn't work.
So there is a small chance that I arrive on the day and hate you, my output won't work.
So yeah, we hit that issue.
So I was hoping to do the whole demo directly on the Mac Mini, but we had to go to Plan
V on my Chromebook here.
But I still got through it, and we'll still do all the Q&A.
I was hoping to show you a couple of things live, but yeah, we'll have to shelve that.
So yeah, I'm Eric Orton.
I work for Red Hat.
I work in the automotive org.
So that's what I kind of work on.
I had a competition, but I have to shelve that because it required the hardware.
We'll see.
If we have time at the end, I might try and plug in the HDMI one more time.
So why do we care about Fidora and Apple Silicon?
So Apple released new Android, Apple Silicon devices, I think it was late 2020.
And there's actually a shortage of well-upstreamed devices.
What's cool about this one is the firmware is unlocked out of the box.
So it's actually a feature of the Mac devices to run alternative operating systems.
And virtualization is also unlocked in the firmware as well.
That's actually a feature I find quite handy.
I run KVMs a lot on this Mac Mini.
Yeah, and it's pleasantly fast.
And I suppose Apple will be known for selling, marketing their hardware as premium, which
it is, but it's also great value, great bang for a buck in terms of performance.
So why do I care?
Why did I get involved?
I'm repeating what I said earlier, I work in the Red Hat on the automotive org.
The automotive boards are ARM based, so I end up doing quite a bit of work that requires
some kind of an ARM environment, and working on the Mac Mini allows me to iterate quickly.
And then as a bonus, I learned more about ARM hardware and software implementations
and things like kernel space rust and that kind of thing.
So these were benchmarks.
I did these well over a year ago.
I was working a bit, I know it might be quite small and difficult to see.
I was working with lib camera at the time, and I just used it as a program to profile
different pieces of hardware I had around the house.
So it's basically minutes it takes to build lib camera or seconds even.
So the bar on the very left is Raspberry Pi 4.
The green one is interesting, that was my phone, it was like a mid-range Motorola.
I'd like a fedoresh P-Root, it's called, the piece of software.
So I'd like a fedora container running on my phone.
So that's the green one.
The yellow one is also a fedora container running on my phone, but yellow is when my
phone is routed, so I can get an extra little bit of performance out of that.
That was using Sheroot rather than P-Root.
And the yellow is my company-issued laptop, which is like an Intel i7, and the small blue
bar at the end is how long it was taking me to build lib camera on my Mac mini.
And finally, the orange bar, my company-issued laptop is twice the cost of the Mac mini,
so that's kind of going back to, there's great bang for a buck with the Apple device.
So what makes the project great, we've really great upstream folk and we collaborate with
these quite frequently.
So Hector, Alyssa, Sahelina, Dugal, Sven, Mac, and there's many more as well.
So we've great downstream folk as well, Neil and Davide are actually here, they're big
in the whole fedora ecosystem, they're big contributors.
Michelle, Leif Liddy is another guy, helps out quite a bit, and there's many more.
So this is another thing that I really love about the Asahi community in general.
They have this kind of upstream everything attitude, so like absolutely everything we
send to the various upstream projects, if at all possible.
And that's one thing, there's various certifications around ARM devices, like Alyssa did just
three there, I could find.
One is work through a Chromebook, and one is the Red Hat Enterprise Linux certification,
and the third is system-ready, but one thing that's in the spirit of all those certifications
is upstream everything.
And yeah, that's one of the kind of core values we have.
And that's actually not as common as you would think with ARM devices, it's almost an exception
when absolutely everything gets upstreamed.
So in Fedora Asahi, this is a further workflow, so most of the time things will hit upstream
first, and then Fedora will package that up, and then the Fedora Asahi remix will use those
packages, so that's the common case.
We also use this workflow, because sometimes submitting things upstream, it can take a
bit of time, so that's a lot of our work as well in the Fedora Asahi community, so sometimes
work will be submitted upstream, but it might not be accepted yet.
So in Fedora Asahi, we'll take those patches, and we'll fork whatever packages we need to
make sure you have the best experience possible while things are still being upstreamed, and
eventually that will make its way to Fedora when it gets upstreamed, and yeah, I'm going
to explain that further in the next few slides.
So yeah, AbsolutelySense is a success when it comes to Fedora Asahi, so ultimately we
plan on getting as much as possible into the main Fedora repository, so every time a forked
package is obsolete, I would regard that as a success.
So what do we fork?
We fork Ubooth, that's kind of one I'm kind of expecting could be forked almost forever,
because we have some Apple Silicon specific stuff in there, I knocked off my mic, 2 seconds.
So we have Ubooth, we have a package we call Kernel, which is our own kernel, it's separate
to the normal Fedora kernel, we have another kernel we call Kernel Edge, we fork Mesa,
we have this kind of firmware package that Hector and the Med called M1N1, and there's
a handful of others.
What were the reasons Ubooth is going to be forked?
I think we have some flags, build time flags, and we don't have a way of changing how it
behaves at runtime yet.
I could be wrong, it may not remain forked, the other thing about Fedora as well, we generally
try and avoid maintaining firmware and focus on the operating system side, so if you notice
our Fedora ARM images, they generally don't get packaged with firmware, we try and avoid
getting into maintaining firmware, because I can scale quite badly at the lower level
pieces of software.
So Fedora kernel, it has Apple Silicon support, it boots, we continually test and enable
more kernel cotton figs as support gets propagated upstream, it's built with 4K page size.
So that's something interesting in Fedora, we try and just build one kernel per CPU architecture,
so at least the way things currently are, we don't build a kernel for 4K, for 16K, 64K,
because yeah, against scale, it's easier to maintain one kernel per CPU architecture.
So something interesting about this kernel is not everything at the moment is upstream
to its support for 4K page size, that's something that's continually in progress and the upstream
folks are working on, but hardware is designed to work with 16K page size, so we'll get there.
Getting everything working with 16K page size upstream is definitely the priority first.
The other thing about 4K page size is you take a performance hit because the hardware
is kind of tuned for 16K page size, so that's something to bear in mind.
So yeah, the Fedora ASAHI SIG then maintains two kernels and this is the first one, I called
it the Fedora ASAHI kernel here and so it uses the Fedora kernel as a base and we didn't
add extra yet to be upstream patches from like the ASAHI Linux repos, we enable even
more kernel configs, we build with 16K page size and it uses simple DRM, which is software
rendered graphics and that's actually surprisingly fast, I'm always amazed at how fast simple
DRM is on hardware like this, so if you're interested in Fedora ASAHI from a user perspective
I would recommend this kernel or the next kernel I'm going to talk about because just
the user experience is a bit better, more things work basically.
So this is another kernel we maintain, we create this one not so long ago, just before
Christmas, so this uses the Fedora, the last kernel I talked about basically as a base
and we add even more patches and we enable even more kernel configs.
So it uses accelerated graphics, what I had intended to do for this talk is that we would
have a little competition of two people playing SuperDoc's cat just to show off the accelerated
graphics but yeah, HDMI issues.
So I found this kernel interesting to work with because it's built with the Rust for
Linux kernel space port and yet the DSAHI GPU driver is one of the first fully fledged
Rust for Linux drivers and it's pretty neat, it works well.
And another difference is we build this kernel with Clang LLVM because basically GCC Rust
support is a little bit behind so at a minimum you have to build a Rust code with Clang LLVM
and I remember playing around with that package at the time and at that point it was just
easy to build the whole code base with Clang LLVM including all the C code.
But I think it is possible if you kind of want the hybrid builds to build the C code
with GCC and the Rust code with Clang LLVM but we switched everything to Clang LLVM at
least temporarily because it's easier and we also use a forked method package so that
works with the Rust GPU driver.
So what's our official release date, Davide, he's here somewhere, I was talking to him
before the talk, he's presenting this stuff at scale in March in about a month's time.
I hope he has better luck with his CMI output and that kind of thing than me.
So yeah, Davide is handling our release so we think we should have an official release
out before that.
So most of the people working on this are kind of doing it part-time except for the upstream
folk, they're more or less, some of them are full-time jobs so we're always welcome
and open to have new contributors.
So if you're interested to reach out to us on Matrix, Apple, it's actually pretty impressive
they seem to be releasing new hardware pretty frequently and every time they release new
hardware there's new things to do because every piece of hardware has its own nuances.
Like this is something we were talking about in the last month or two, I don't actually
have an M2 device so I can't test it personally, but WebKit is basically broken because there's
this thing, it's a new feature of Armacam and Arm version 8.5 and it's called branch
target identification and basically WebKit, basically someone has to write the code in
WebKit to say if BTI do this but nobody has done it.
Which is interesting, I remember yesterday at an ampere talk somebody asked a question,
can new Arm versions break user space and I didn't want to answer because I wasn't speaking
but yes they can sometimes because this is one of those cases.
And that's kind of it, I have a couple of links there to our Matrix, our Wiki, our Project
Tracker, the upstream, Sahil Linux.org page and this Git and Copper, you'll find some
of our PM's in there if you're interested.
Yes so that's kind of it, I'll take Q&A now if anyone has questions and answers and if
we don't and we have a little bit of time, I might plug in the history, might cable one
more time to see if we get very lucky.
Still anybody have questions?
At the beginning you mentioned that Apple Silicon is well upstreamed on ARM device,
what do you mean by being well upstreamed?
As in like does it have work to put back into it?
Could you repeat the question?
In the first slide you said that Apple Silicon is a well upstreamed ARM device, which is
why you work on it, what does that mean exactly?
So that's all thanks to the upstreamed fork, the Sahil Linux fork.
So Hector Martin is the leader of that and he really believes in upstreaming.
So like he tries his best, sometimes certain piece of code, yeah he does get difficulty,
that's normal, it spends so many subsystems and so many different projects.
So the world is top-streamed, absolutely everything.
I pointed that out, there are like plenty of ARM SLCs that publish their code, so they
like put a Git hub repo out and they'll publish the code there, but they'll never, often they
don't code a final hurdle and get it like into Linux history, so like it runs out of
the box with Fedora, Debian, Ubuntu, all the various distributions.
And that's one of the things I love about the Asahi guys, because they go that extra
mile to try and upstream everything, so that's what I meant for that.
Hi, you mentioned that you think that might not be upstreamed, would it make sense to
have a separate project to create an UEFI layer on top of that, to harmonize Fedora in
that way?
Yeah, I'll be honest, I did not work on the Ubuntu stuff myself, I think Hector did most
of that, he calls it EFI like and not exactly EFI, so that might be the reason why it might
remain a fork.
To be honest, I work more with the downstream folks, so you'd probably have to talk to the
upstream Asahi guys about that.
I think it was Hector working on the Ubuntu stuff, but I could be wrong.
I'll try and plug in the heads to my...
Hi, thanks for the talk, I would like to know how it is to use a new programming language
which is Rust in the kernel and in Mesa, is it going to be supported upstream?
I think it's amazing, I'm not going to lie to you and say I've written thousands and
thousands of lines of Rust, because I haven't, but building it is easy as long as you're
applying LLVM at the moment, and I believe GCC started to release Rust support recently,
so I expect GCC to get there as well eventually, so building it isn't too bad now.
Building it, it works solidly, I've never had any crashes or anything.
Hector and all those upstream guys swear by it, they reckon like they got that GPU driver
written twice as quickly just by using Rust, and by not having to handle memory management
manually always and all these things, and they handle trade races and stuff.
I think another reason they chose Rust is I think when Rust engineering the Apple GPU
driver I think it was written in C++, so I think it made a little bit easier for them
because Rust has some of the features of C++, but they swear by it and they're the guys
that actually write the Rust kernel of Hatches not me.
Do you see a need or a demand for or use for Apple Silicon to run Linux servers in real
scenarios in companies and this kind of stuff?
Like in enterprise?
Yes.
Enterprise is tricky because we're very much a community supported effort and we don't
have any, Apple don't really have an issue with us doing this, but we also don't have
an official relationship with Apple, so it would be hard to deploy Linux and Apple Silicon
in a data center when you don't have support, official support from the hardware manufacturer.
So at the moment I don't see that happening, unless Apple all of a sudden are like, yeah,
we'll support that configuration like in an enterprise environment, yeah, could happen.
Where did the HDMI cable go?
I'm just going to plug it in there.
Sorry guys.
Hi.
Sorry, I was just going to wonder, you mentioned that for Uboot you weren't going to push
things upstream from your fork, is that a licensing issue, like is it a GPL conflict
or something like that or what's the problem?
Could you repeat the question a little bit louder?
I think earlier you said that for Uboot you would be maintaining a fork, is that a licensing
issue, like is there something you can't commit back to Uboot that they wouldn't accept?
Yeah, I didn't, again I didn't write the Uboot patches, I'm pretty sure that was Hector.
I think it's because it's written in a non-standard way, like he often calls it UEFI-like and
I think there's certain hacks he had to do to get it working on Apple Silicon that the
maintainers may not accept, but I will repeat, does upstream, the upstream Asahi community,
they really care about upstreaming into the real projects be it Linux, kernel, Mesa, etc.
So if all possible, I'm sure they will, you know.
Sometimes there's just hacks required because it's built around macOS at the end of the
day.
Some questions?
I'll be around for the day, if any of you see a monitor around the campus or whatever
and you want to see it in action, we can hook it up and try, I'm all into that.
So yeah, it's about, I've seen this happen before, 90% of monitors work, so if you find
a random monitor, yeah, we can do it.
Okay, so thank you, Eric.
Thanks guys, thanks very much.
Thank you.
Thanks, Eric.
Thanks, guys.
Thanks, Eric.