From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 76C7920D2C3B9 for ; Wed, 29 Mar 2017 10:58:59 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DB21CC05AA52; Wed, 29 Mar 2017 17:58:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DB21CC05AA52 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DB21CC05AA52 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-134.phx2.redhat.com [10.3.116.134]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5C66F173A2; Wed, 29 Mar 2017 17:58:57 +0000 (UTC) To: Mark Rutland References: <20170329151940.23397-1-ard.biesheuvel@linaro.org> <7F72156F-3814-4CF1-8847-A7272409A85E@redhat.com> <52dc0685-ae37-63db-d7b5-feb49490a12d@redhat.com> <20170329174408.GC26135@leverpostej> Cc: Ard Biesheuvel , Jon Masters , Marc Zyngier , "edk2-devel@lists.01.org" , Drew Jones From: Laszlo Ersek Message-ID: <34f8245c-d46d-6a7f-5046-df0c04fb08df@redhat.com> Date: Wed, 29 Mar 2017 19:58:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170329174408.GC26135@leverpostej> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 29 Mar 2017 17:58:59 +0000 (UTC) Subject: Re: [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:58:59 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/29/17 19:44, Mark Rutland wrote: > Hi, > > On Wed, Mar 29, 2017 at 06:55:26PM +0200, Laszlo Ersek wrote: >> On 03/29/17 18:17, Ard Biesheuvel wrote: >>> On 29 March 2017 at 17:09, Jon Masters wrote: >>>> Thanks Laszlo. A quick note from me that regardless of this >>>> discussion I will be pushing to ensure the version Red Hat ships >>>> makes ACPI the default with it being extremely painful to use DT. >>>> It is time the ecosystem got with the program we all agreed upon >>>> and there will be no more excuses. >>> >>> This has *nothing* to do with the ecosystem. This has to do with >>> existing users of ArmVirtQemu (admittedly, a small fraction) that will >>> be forced to compile their UEFI images from source because we made a >>> backwards incompatible change. >>> >>> I am 100% on board with making ACPI and DT mutually exclusive. But I >>> don't believe for a second that 'everybody just exposes ACPI and DT at >>> the same time' if this gets merged. >> >> That's where we disagree, 100%. >> >>> That happens because people are clueless, not because they are >>> deliberately spending time and effort on producing two hardware >>> descriptions. >> >> If this were true, then the kernel's preference would have been changed >> to ACPI aeons ago (assuming both DT and ACPI were present). > > As has been covered elsewhere, unilaterally changing the default breaks > existing systems, regardless of what vendors do from now on. > >> ACPI is superior to DT (cue again Grant Likely's blog post), yet >> kernel people resist it. > > In several respects, sure, though let's not be under the illusion that > it is not free of novel technical problems. > > The big deal with ACPI is that there are other major OS vendors who will > support ACPI, but not DT. To avoid a fragmented market, commodity > servers must use ACPI. > >> That's not cluelessness. If the kernel's DT camp has any >> influence on platform vendors (and that's rather more a "given that" >> than an "if"), when they find out about this loophole, I expect them to >> actively recommend it as a way to perpetuate the status quo. > > Who is this "DT camp"? I assume the people who have thus far prevented the preference switch-over from DT to ACPI, provided a system exposed both. I realize (as you say above) that this might render some systems temporarily unbootable. Yes. But without that pain, no platform vendor will *ever* be incentivized to get their ACPI tables in order. So the idea here is to force that pain from the firmware side. On one hand, it is a regression, yes. On the other hand, if it's not broken (intentionally), why would anyone ever fix it? (This argument is based on the fact that the shippers of broken ACPI tables actually label their machines SBBR-conformant. Nominally, they *want* to support ACPI.) > As a DT binding maintainer, I would be livid were people recommending > using this in generic OS images. The kernel still prefers DT over ACPI if both are present; that's just the same mindset. Laszlo