Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Mon, May 08, 2023 at 06:16:52PM +0100, Pete Batard wrote:
> Plus, UEFI has an official standard, and standards are (for the most part) a
> good thing.
IEEE-1275 is a standard too.
> However, with what I have mentioned initially and the weight that Microsoft
> has, the only way you're going to have vendors moving away from ACPI is if
> Microsoft decides to add support for DT in Windows (or something else that
> they see better than ACPI)... which I don't really see happening in the near
> to medium term, since, much to their benefit, Microsoft did manage to get
> the ARM SBBR specs to go with ACPI and thus continue business as usual as
> far as Windows is concerned.
>
> Again, I am hoping that there was some consideration given by Microsoft and
> other members of the SBBR committee as to whether it made sense to go with
> Device Tree. One of the problems I would see however is that, I doubt the
> Linux folks consulted with Microsoft when they introduced Device Tree (then
> again why and how would they) to see if Microsoft had some interest for
> using it in the long run, and if so, what they could do to make it more
> palatable for Windows usage.
Well devicetree is part of open firmware aka IEEE-1275, from 1994.
ACPI is from 1996. 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.
> And that's the old problem of ecosystems being split on OS lines, when it
> would be nice if we could look a bit further than that, with Linuxfolks most
> likely not that eager to ask Microsoft if they have some input on the
> direction they wanted to take when they introduced DT, and, likewise,
> Microsoft unlikely to want to use some "Not Invented Here" technologies like
> DT, even more so when you have the other elephant in the room for the "Not
> Invented Here", i.e. Apple, which seems so adverse to compromising with
> anybody that it provides the worst example to follow such as, using their
> own version of EFI on x86 based hardware rather than UEFI, and then dropping
> that altogether on their ARM based silicon, to now use their own completely
> custom pre OS execution environment. At this stage, I should probably add
> that it's going to be fat chance to ever see Apple use SBBR on their
> hardware even, if on paper, it should have been a perfect target for it and
> sure would have make booting and installing Debian on Apple Silicon
> easier... even if one were to be constrained to use ACPI over DT.
Apple is almost certainly back to devicetree on their arm devices since
they used it on their powerpc based systems already in the past.
> To me, it looks like mostly a question of reducing development cost as well
> as what one can get away with by not going out of their way to try to talk
> and seek compromise with other parties. And, as usual, it's the end-users
> that pay the price by having hardware and OSes that restrict what they
> should be able to do with it, starting with their ability to install the OS
> they prefer on modern ARM64 hardware.
>
> And that's actually the reason why I think efforts like SBBR should be
> supported, because they are trying to break the status quo, even if it
> appears that Microsoft might have gotten what they wanted at the detriment
> of Linux, and even if Apple are unlikely to ever want to touch SBBR with a
> ten foot pole...
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
unless you were google or amazon or some other large cloud provider.
Apparently they didn't actually want to sell their systems. Then they
complained that there was no market for arm servers. Maybe it has gotten
better in the last few years, but in my current job having arm servers
is no longer relevant unfortunately. I sure wanted some 8 or 10 years
ago when they were announcing them but not actually selling them.
> 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.
> And that is the main issue here. SBBR is not just for Linux, or for Windows.
> So, yes, someone, on the OS side, is likely to have to do extra work, whose
> only purpose will be to allow people to install a completely different OS.
> And yes, that sucks. But if it benefits end-users, it's the price one has to
> pay.
It seems that it benefits only one OS, the one it seems just about no
one cares to run on arm systems.
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.
--
Len Sorensen
Reply to: