On Tue, 1 Sep 2020 at 14:26, Peter Robinson <[email protected]> wrote: > > On Tue, Sep 1, 2020 at 12:21 PM Grant Likely <[email protected]> wrote: > > > > > > > > On 01/09/2020 12:06, Heinrich Schuchardt wrote: > > > On 9/1/20 12:45 PM, Grant Likely wrote: > > >> Early in EBBR discussions the decision was made that firmware should not > > >> provide both DT and ACPI at the same time. The reasoning had been that > > >> we didn't want to encourage 'hybrid' approaches where the OS tries to > > >> consume both DT and ACPI descriptions. > > >> > > >> However, this fear has not so-far born out, and feedback has been that > > >> requiring a boot-time switch to select either DT or ACPI is a support > > >> issue for OS vendors. They would rather see ACPI (or DT) always turned > > >> on if it is an option and the OS can choose to use it or not. > > > > > > Which OS vendor are your referring to? > > > > > > Why does that OS vendor not implement both ACPI and DT support to > > > encompass as many devices as possible? > > > > Sure; in concrete terms, this is what I see among the major OSes: > > > > Linux: support both; consumes DT by default. (some distros change the > > preference; "acpi=force" forces kernel to use ACPI instead) [1] > > BSD: Both (?) > > Windows: ACPI only > > VMware ESXi on Arm: ACPI only > RHEL on Arm: ACPI only. > > > > What would we expect to happen if the ACPI and DT content are not > > > equivalent? > > > > Then the OS would get the functionality of whichever system description > > it chose. The experiments with ACPI-only OSes on Arm SBCs have shown > > that there is interest in supporting the platforms, even if the initial > > functionality is reduced due the not all hardware having a usable ACPI > > description (lots of reasons for this from hardware design not fitting > > nicely into the ACPI model, to lack of bindings, to just hasn't been > > looked at yet) > > Also network and storage interface, possibly others, names often > change just due to the way naming//bindings/IDs are handled between > the two. >
The crux of the matter is that platform X described via ACPI cannot be assumed to be the same as platform X described via DT. Peter points out the device naming changes due to different enumeration order, but there are many other issues (NUMA topology, RAS features etc). So there can be no guarantee whatsoever on OSes that are able to support both descriptions that any OS or HW configuration state can be preserved across a switch from ACPI to DT or vice versa. I understand how on the face of it, permitting both to coexist might seem like the easiest approach from the platform vendor POV, but I think this is a mistake. Making it the system's job to choose one description or the other removes any ambiguity, and therefore prevents problems. I understand how OSVs like MS entering the space that has historically been dominated by DT are eager to make the switch seamless for them, but doing so creates problems for Linux, so I would prefer not to go down this path. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
