On Tue, Apr 05, 2016 at 10:43:11AM +0200, Linus Walleij wrote: > And these products are only update-able > with hairy BIOS patches that need to be applied > using $SPECIAL_TOOL that "normal users" do not want to > concern themselves with, as this is not an "apt-get upgrade" > kind of thing. This bit has been addressed in UEFI - there's now a mechanism for the OS to supply firmware updates to the BIOS via runtime sevices calls without needing to go to the hairy tools. There's also been facilities for some time which allow ACPI fragments to be loaded at runtime without patching the firmware (though they're not used so often at present). > And I think that is what is happening, it's just that so much > prestige is involved that no-one wants to officially admit it. > I was once poking fun at this development model accusing > firmware engineers of having a God complex when they claim > to be able to engineer in these complex use cases during That's not really a fair characterization of the situation. The goal that ACPI has been trying to meet is allowing new hardware to work without needing software updates so people's installation experience isn't miserable. The Windows monoculture that firmware developers have been targetting has hurt the achievement of that but it's the idea. It's a good model for some classes of device but not for all. > product firmware development. Now I just feel sad about this > situation and want things to "just work" for them. I think these > patches are good. See Mark Rutland's reply - there's a whole model behind how ACPI abstracts the system that needs to be taken into account, just stuffing the existing DT in through a mechanism intended for simple vendor specific key/value properties isn't guaranteed to give something that's coherent and sensible. DT design decisions will obviously not have considered ACPI and exposing the full combination of the two system models to system integrators seems likely to lead to unfortunate corners, especially with things that happen to work right now but cause problems later on. Given the rush to shoehorn existing DT into ACPI at some point it's looking like it would be much more sensible for x86 to just do what arm64 has done and support both DT and ACPI in parallel and let people (either system integrators or end users) choose the most appropriate interface for their application.
Attachment:
signature.asc
Description: PGP signature
