Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
Well, I guess at this stage, and to help provide some more context about
the DT vs ACPI conundrum, I'm going to stop tiptoeing around the literal
elephant in the room, but not without first adding a preliminary notice
that I wasn't privy to whatever discussions occurred with regards to the
SBBR standard (I'm just a mere downstream developer, that got involved
well after SBBR was crafted), so part of it is yet again going to be
pure speculation.
The "elephant" in the room, in our case, is Microsoft since, from what I
understand, they did drive part of the design of the standard... which
of course makes sense since they do have an OS that they would like to
see people install on ARM servers and therefore will be interested in an
emerging ARM standard that's likely to affect them. And likewise, the
ARM folks, when devising a new standard, most certainly wanted feedback
from the company that still holds the lion's share of installed OSes out
there. So, any decision that was taken as part of the writing of the
standard is likely to have had Microsoft's footprint in one way or another.
That's not to say that (again from what I understand) Microsoft got free
reign, and that people interested in promoting the standard for Linux,
BSD or something else got the short end of the stick. But of course, now
that you know that Microsoft did play a part in this whole SBBR
endeavour, it might give you yet a different perspective on this whole
ACPI vs DT matter...
On 2023.05.08 12:15, James Addison wrote:
Somewhat agree, yep - although I think that in this case, there should
be various paths available (u-boot, EDK2, ACPI/DT), and if possible
I'd like to understand what is the approach that provides the most
compatibility and free software support with the fewest moving parts.
To me, the reliability and human-time cost savings from simpler, more
open and straightforward systems outweigh many other factors,
especially over the long term.
Agreed. But to others such as Microsoft, not having to integrate
something foreign when they already have good support for both UEFI and
ACPI in their OS was probably something that they had some strong
opinions about. In other words, while I like to imagine that Microsoft
did consider whether it would make sense to add support for DT for
Windows on ARM, and ultimately decided against it on a technical basis
rather than on an "it'll make life simpler for us", it appears that the
consensus settled on not having DT being part of the standard.
That's partly the reason I've been wondering about the power
consumption and operating-system-compatibility questions: as I
understand it, those were key reasons that server hardware vendors had
a preference for ACPI when determining the server standards in the
mid-2010s, and so a few years since then, it could be helpful to
figure out whether those continue to make a difference, and how
Devicetree/FOSS driver implementations compare.
If Microsoft and the people who drove the SBBR standard did review
things objectively, this might indeed be part of why they decided not to
add DT support.
I think that's great, and I've had a good experience with EDK2 +
Devicetree. My concerns about ACPI are basically that it seems like a
less-readable, larger-surface-area standard with more opaque processes
surrounding it. But I'm not an expert.
Yeah, neither am I, and I'll trust Linus and the kernel folks when they
decided that ACPI was such a liability that they had to devise something
better... This being said, I do wonder if DT has been holding all its
promises and doesn't come with its own pitfalls, now that we've seen it
used in practice for a few years. At least, as someone who has had to
help with implementing code that *alters* the original DT provided by
the Pi Foundation, so that it can actually be used downstream of UEFI
boot (which is something we have to do in the current Pi UEFI firmware
[1]) and has had to look from the sidelines at the annoyance of still
having to use a compiled-in format (couldn't some bz2 of plaintext, with
a little extra processing/runtime compilation from the kernel, work well
enough so that one could make editing of DT a lot friendlier for the end
users? Talk about doing away with binary formats...), I can't say I'm
entirely convinced that DT couldn't have been improved further.
Getting slightly further off-topic, but for my own education: what is
an example of a UEFI feature that a user might want to use?
Well, the big one would of course be Secure Boot.
Others would be the ability to have an interface from the OS, that
allows one to modify boot order/boot entries and read/write some
(relatively) standardised pre-boot environment variables. Oh and don't
forget the ESP, which is a lot more user friendly as a means to alter
your bootloaders and boot environment (just copy/edit at the file system
level, from your OS and with your utilities of choice, or use a full
blown shell if you need to) than using the (AFAIK) much more limited
means of accomplishing the same with something like u-boot.
Plus, UEFI has an official standard, and standards are (for the most
part) a good thing.
(to my mind, most of my preferences are: I want to use a standard,
easily-obtained installer,
I believe UEFI gives you that.
for each system install to be straightforward
Well, the standardised ESP and boot variables of UEFI should give you
that too (that is, as long as Microsoft doesn't abuse the ability to
change/alter the UEFI boot entries from the OS, in order to disregard
the user's choice and force Windows first, which they do tend to do).
and for the system to boot, for each system's devices
to function correctly,
Before OS handover, if your bootloader is UEFI compliant, it will have
access to all of the system's devices for which UEFI has a driver.
and for those to occur while minimizing the
amount of extraneous runtime code and I/O (roughly in that order of
precedence, and with FOSS practices helping a lot to achieve and
maintain those in the long-term).
I'd say UEFI drivers are usually fairly lean, at least for the base ones
provided by EDK2, even if supporting the UEFI standard may make it look
like they are encumbered with extraneous stuff. But that's standards for
you, and they exist to ensure that, if you do follow them, you're not
going to end up with something like a nasty Linux Shim boot loop for
instance (which is something that recently happened to me with a driver
I had put together, and that wasn't fully UEFI compliant [2])...
perhaps ranty, but it's intended to
explain why I don't love standards that include unusual and/or
unproven quirks, and binary blobs)
As we've seen above, I'd go further than that, and consider that DT
isn't exactly ideal in that respect, as it still, in essence, works with
binary blobs...
As to quirks, for having worked with the EDK2 folks, I'd say that if
there's something that they strive to avoid, it's unusual quirks or
anything that's left open to interpretation (which is another thing
that's caused me some grief with the RPi UEFI implementation, as we did
identify an element from the specs that was subject to interpretation,
and the specs were refined... but in a different direction than what we
would have wanted [3]).
If I were to imagine a two-line chart of device and hardware support
over time, with one line each representing the ACPI and Devicetree
approaches, then based on this standardization and industry backing, I
would expect ACPI to be the upper line for some duration of time
(decade?) until the point at which the drawbacks and disadvantages of
the extraneous functionality and complexity that I sense (but can't
really confirm, yet) outweigh the industry momentum placed behind it.
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.
And I think that's a shame, because if the same effort and backing had
been placed behind a simpler, more open and maintainable approach
(namely the other line, Devicetree) then I think that overall
ecosystem cost savings and user/consumer respect improvements could
have been increased -- and that _should_ be good business.
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.
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.
Ultimately it feels like a question of time, though, and
delaying progress based on revenues and partnerships from a margin of
unnecessary cost passed on to purchasers feels wrong.
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...
My understanding is that the Linux development community has (and
continues to) pay the cost of maintaining ACPI compatibility, while
Devicetree (also with cost to support and develop) appears
well-supported across multiple architectures
Well supported across architectures: yes.
Well supported across OSes: Unfortunately no, when you do consider Windows.
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.
Regards,
/Pete
[1]
https://github.com/tianocore/edk2-platforms/blob/master/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c#L470-L507
[2] https://github.com/rhboot/shim/issues/558#issuecomment-1490993221
[3] https://bugzilla.tianocore.org/show_bug.cgi?id=3336
Reply to: