On 29 March 2017 at 17:03, Laszlo Ersek <[email protected]> wrote: > On 03/29/17 18:02, Ard Biesheuvel wrote: >> On 29 March 2017 at 17:00, Laszlo Ersek <[email protected]> wrote: >>> On 03/29/17 17:19, Ard Biesheuvel wrote: >>>> In general, we should not present two separate (and inevitably different) >>>> hardware descriptions to the OS, in the form of ACPI tables and a device >>>> tree blob. For this reason, we recently added the logic to ArmVirtQemu to >>>> only expose the ACPI 2.0 entry point if no DT binary is being passed, and >>>> vice versa. >>>> >>>> However, this is arguably a regression for those who rely on both >>>> descriptions being available, even if the use cases in question are >>>> uncommon. >>>> >>>> So allow a secret handshake with the UEFI Shell, to set a variable that >>>> will result in both descriptions being exposed on the next boot, if >>>> executing in the default 'ACPI-only' mode. >>>> >>>> setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceDt =01 >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> Signed-off-by: Ard Biesheuvel <[email protected]> >>>> --- >>>> ArmVirtPkg/ArmVirtPkg.dec | 8 ++++++++ >>>> ArmVirtPkg/ArmVirtQemu.dsc | 3 +++ >>>> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 7 ++++++- >>>> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 5 +++++ >>>> 4 files changed, 22 insertions(+), 1 deletion(-) >>> >>> Nacked-by: Laszlo Ersek <[email protected]> >>> >>> This will cause everyone *at all* to set the secret handshake, and we >>> will be back to square one, where everyone just exposes ACPI and DT at >>> the same time, and delegate the decision to the guest kernel. >>> >>> And then vendors will continue to ignore ACPI testing, and they will >>> continue shipping crap in their ACPI tables. >>> >>> We might as well rip out the recent patches that implement the mechanism >>> and the policy for the mutual exclusion. >>> >>> As Leif proved so eloquently (in the pub) in Budapest during Connect, no >>> OS needs both descriptions at the same time. Virt users can make up >>> their minds about what to expose. We (RH virt) had been worriedly >>> planning to make the same proposal to Leif, you, et al, and then we were >>> happy to see the violent agreement that ensued. >>> >>> Sorry for getting political, but the kernel's unwavering preference for >>> DT over ACPI is political, and the recent edk2 patches only exist to >>> rectify that, from the firmware side. Users don't lose DT. What they do >>> lose is the (harmful) freedom of not choosing one over the other. That >>> freedom has had a terrible effect on the quality of ACPI tables shipped >>> with *allegedly* SBBR-compliant hardware. >>> >>> Feel free to diverge from this in downstream distributions, but this >>> loophole has no place in upstream edk2. >>> >>> NACK >>> >> >> OK, fair enough. How do you propose to handle this regression then? >> > > I don't.
I think I am entitled to a more constructive attitude from you. I don't care about politics, but I do care about not breaking people's workflows. So if you insist on getting on your high horse and throw capitalized NACKs at me, you could at least *pretend* to care about other users than *your* downstream, and come up with some alternative. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
