On 2023.05.08 21:02, Lennart Sorensen wrote:
Well devicetree is part of open firmware aka IEEE-1275, from 1994.
ACPI is from 1996.
Interesting; TIL.
I guess I'm probably not the only person who thought DT was something
that was only cooked recently by Linux kernel maintainers, since that's
when it became mainstream for the majority of the x86/PC based end-user
crowd.
And of course since I don't think Sun cared at
all what Microsoft thought when they designed the firmware interface,
I don't think that matters. Since open firmware or at least devicetree
has then ended up used on SPARC, PowerPC, ARM, MIPS, and who knows what
else, while ACPI is x86 and now some ARM but nothing else as far as I
can tell, other than in terms of overall units using it, ACPI certainly
has a lot less interest.
Well, the thing is overall units tends to correlate pretty closely to
overall end-users. And, while one may try to plan for what one
expects/hopes the end-user landscape to shift towards, one must still
strive to create software that makes life easier for the current one. In
terms of units, ACPI has certainly been more widespread, even if it's
mostly due to the homogeneity of the dominant arch and platform (x86
based PC).
Apple is almost certainly back to devicetree on their arm devices since
they used it on their powerpc based systems already in the past.
If that's the case, then (I'm going to assume that) it's shame Apple
didn't use their position to join the discussion and provide some
opposition to Microsoft, when it came to going with ACPI-only for SBBR...
Well unfortunately for years it seems the status quo has also been 64
bit arm servers being annonced, but not able to be purchased anywhere
I'd venture to say that there's been a bit of a chicken and egg problem
there, which SBBR is in part trying to solve, by attempting to remove
one of the hurdle people face when getting an ARM64 server, i.e. how the
heck am I going to install my OS/distro of choice on this machine,
instead of being constrained by whatever custom version of some other
OS/distro the manufacturer of the platform decided to go with.
I do agree that we're still early in the game here, if game there
eventually is, which is the *precise* reason why a group of us worked
together to provide an SBBR implementation on the commonplace and
relatively limited Pi platforms, i.e. something that is everything but
an ARM server, to both provide an easy to access working implementation
as well as demonstrate to ARM64 system manufacturers that, if this can
be accomplished for the Pi with limited effort, this should certainly be
achievable for their platform.
Well supported across architectures: yes.
Well supported across OSes: Unfortunately no, when you do consider Windows.
Any OS that ever ran on an openfirmware system, which is a lot of them.
Again, I'd prefer to go with number end-users as a better measure, since
we're not developing for the greater variety but for is likely to
benefit the greater masses. Of course, if ARM64 system manufacturers
collectively decide they want to ignore Windows and SBBR, and go with
openfirmware, I'll be more than happy to let Microsoft add openfirmware
compatibility to Windows on ARM, as long as the end-users stop having to
jump through system-specific hoops to install the OS they want.
It seems that it benefits only one OS, the one it seems just about no
one cares to run on arm systems.
I'm going to go further than that and say that not even Microsoft
appears/appeared to care that much about running Windows on ARM systems,
as we pretty much offered them a golden opportunity to chase a goal they
should be exceedingly familiar with, and, what's more, one that Apple
will never challenge them on, namely running their OS on *cheap*
commonplace hardware. But they pretty much ignored the crowd that was
interested in running Windows on the Pi, even as Windows 11 21H2 does
run very decently on an 8 GB Pi 4 and, current hardware price hike
notwithstanding, could have gained significant traction with the low
income masses. This, in turn, could have provided Microsoft with a means
to bring (or should I say lock-in) those masses into the Windows
ecosystem. But instead, it appears they looked at what Apple was doing
with controlling both the hardware and software through an expensive
platform, and decided they wanted a piece of that pie, which I doubt
will benefit them much in terms of trying to keep Windows as the
dominant OS.
Now, as an aside, since the above may make it look like I'm trying to
advocate for Microsoft and we're on a GNU/Linux mailing list after all,
please bear in mind that, even as I am primarily a Windows developer
these days, I am far from rooting for Microsoft or any proprietary
software company for that matter. In fact, the main software I develop
on Windows is also designed to allow people break away from the
abomination that is closed-source proprietary software, like Windows,
*if they so choose* (since you cannot offer people freedom without also
giving them choice). As such, I am kind of supporting SBBR for Windows
on account that I expect both a server-targeted specification to
percolate to mainstream platforms eventually as well as the masses
running these end-user platforms to be initially more interested in
running Windows, if they have the choice, as opposed to some other OS.
From there, if we have something familiar like UEFI, I am hoping these
users may become more receptive to switching to a free OS. Oh, and for
the record, I have quite a different view when it comes to the interest
there has been with regards to running Windows on ARM, due to the direct
feedback we got once in turned out that the Pi UEFI firmware could be
used to get Windows to run on these platforms, even when it originally
did so with atrocious performance on the severely limited Pi 3. But of
course, that interest wasn't from people trying to run these platforms
as servers in the first place.
Doesn't mean that long term ACPI and UEFI might not be better for SBBR.
I highly doubt the decision was made without heavy bias though.
Yeah, while I do hope that this wasn't the case, I too assume that there
weren't much of anybody in the room to try to counter Microsoft.
But again, I have no idea how ARM and SBBR actually came about, along
with who actually got invited to participate in the discussion, and who
might have declined to do so...
Regards,
/Pete
