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 3D31C1A1E28 for ; Fri, 21 Oct 2016 13:40:30 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9EF85C0567A2; Fri, 21 Oct 2016 20:40:29 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-45.phx2.redhat.com [10.3.116.45]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9LKeRaY029235; Fri, 21 Oct 2016 16:40:27 -0400 To: Ard Biesheuvel References: <147707992484.13791.10042868456965197315@jljusten-ivb> Cc: Jordan Justen , edk2-devel-01 , "Kinney, Michael D" , Leif Lindholm , "afish@apple.com" , "Gao, Liming" From: Laszlo Ersek Message-ID: <878ac061-777d-ec5a-a00b-da84c701cc93@redhat.com> Date: Fri, 21 Oct 2016 22:40:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 21 Oct 2016 20:40:29 +0000 (UTC) Subject: Re: [Bug 164] Add the build option "/D DISABLE_NEW_DEPRECATED_INTERFACES" in package DSC files X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 20:40:30 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/21/16 22:19, Ard Biesheuvel wrote: > On 21 October 2016 at 21:14, Laszlo Ersek wrote: >> On 10/21/16 21:58, Jordan Justen wrote: >>> On 2016-10-21 12:37:21, Ard Biesheuvel wrote: >>>> I don't remember seeing any discussion regarding >>>> DISABLE_NEW_DEPRECATED_INTERFACES on the list, so I am a bit surprised >>>> seeing these bugs being filed and assigned. >>>> >>> >>> I agree. >>> >>> Also, the terminology seems confusing. 'new deprecated' seems like a >>> contradiction. I guess it means 'newly deprecated', but that seems >>> like a term that is quickly going to become obsolete. Soon there will >>> be old deprecated items that are disabled with this switch. >>> DISABLE_DEPRECATED_INTERFACES sounds better. >>> >>> But, shouldn't we have platforms opt-in to using the deprecated >>> interfaces rather than adding DISABLE_NEW_DEPRECATED_INTERFACES to the >>> build command line for every EDK II platform? >>> >>> Not using deprecated items should be the default for EDK II platforms. >>> If a platform has to opt-in to the deprecated content in their .dsc, >>> then it is obvious that they are relying on deprecated functionality. >>> >>> So, I guess I'd propose adding ENABLE_DEPRECATED_INTERFACES instead. >> >> I'm about to post a ~20-part series for OvmfPkg and ArmVirtPkg together >> that solves these BZs. :/ The DISABLE_NEW_DEPRECATED_INTERFACES feature >> test macro is already being used in three MdePkg library class header >> files (and a number of library instances), so I thought it was a done deal. >> >> I don't want to stifle the discussion of course, but at this point I >> think I will post the patches for review. >> > > Yes, please. Removing uses of deprecated interfaces is something we > should do anyway. What we shouldn't do is configure our platforms in > such a way that additional future deprecation automatically break the > build, unless we have a strong commitment from the other package > owners that they will ensure that this does not happen. > Well, my expectation is that the onus of keeping the tree working is on the patch submitter. Assume we adopt DISABLE_NEW_DEPRECATED_INTERFACES now (weaning ourselves off the functions that are *currently* disabled by the macro). Then whenever someone moves further functions under the scope of the macro -- thereby possibly breaking platform code --, it's going to be their responsibility to grep the tree for platform DSCs that enable DISABLE_NEW_DEPRECATED_INTERFACES, and either test-build those platforms reasonably extensively, or ask for help *in advance* (before committing the patches). For example, in the current work I'm about the post, I couldn't build-test everything (no RVCT over here, for example :)) Also I don't run Xen, so the Xen-related changes can't be functionally tested on my side -- but, I do ask for help with testing those. Same goes for the 32-bit ARM changes (which, it turns out, Michael and myself managed to fix separately, independently, and differently :)) It's okay to modify code one can't build or test himself/herself, but then help should be asked for, and given too. TL;DR: the strong commitment you speak about is the default for any open source project, isn't it? ;) Thanks Laszlo