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