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 73B6C1A1DF8 for ; Fri, 21 Oct 2016 14:02:47 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 E9D0FC054904; Fri, 21 Oct 2016 21:02:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-45.phx2.redhat.com [10.3.116.45]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9LL2irK001701; Fri, 21 Oct 2016 17:02:45 -0400 To: Jordan Justen , Andrew Fish References: <147707992484.13791.10042868456965197315@jljusten-ivb> <147708236992.14194.656313834108120082@jljusten-ivb> Cc: Ard Biesheuvel , edk2-devel-01 , Mike Kinney , Leif Lindholm , "Gao, Liming" From: Laszlo Ersek Message-ID: Date: Fri, 21 Oct 2016 23:02:44 +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: <147708236992.14194.656313834108120082@jljusten-ivb> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 21 Oct 2016 21:02:47 +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 21:02:47 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/21/16 22:39, Jordan Justen wrote: > On 2016-10-21 13:20:49, Andrew Fish wrote: >> On Oct 21, 2016, at 12:58 PM, 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. >> >> Jordan, >> I think it depends on your point of view. If you have a platform that >> works and you update the edk2 revision you would expect it to still work. > > I think this is what UDK is for. If you want to depend directly on EDK > II, then you'll see less stability. > >> Thus the option is to DISABLE_DEPRECATED_INTERFACES as that maintains >> backward compatibility. > > In order to support UDK releases, maybe ENABLE_UDK2014_INTERFACES would be > something to consider. Or ENABLE_UDK_INTERFACE=2014 so we can use <=. > > But, I still think that EDK II platforms (as a goal) should represent > the best, cleanest examples of using EDK II. And, I think having every > platform accumulate cruft like CFLAGS to disable deprecated interfaces > works against that goal. > > Another point. What about when we want to deprecate more interfaces? > Oh know, we better not break platforms that only specified > DISABLE_NEW_DEPRECATED_INTERFACES! Let's add > DISABLE_NEW_DEPRECATED_INTERFACES2! :) Honestly, I imagined that DISABLE_NEW_DEPRECATED_INTERFACES would be temporary in the edk2 tree. That is, it's a means so we can gradually transition with all the in-tree stuff to a deprecationless code base. Once that's done -- i.e., *all* platform DSCs within the edk2 tree specify this feature test macro under their respective [BuildOptions] sections --, then whatever the macro excises from the core packages can be removed permanently, together with those platform [BuildOptions]. I think this should prevent the accumulation of cruft in edk2. Yes, downstreams will have to catch up (or use UDK for a while longer). If that's inconvenient, I have a solution: upstream your codebase, and then the community will take care of keeping it in sync with the rest ;) (This is the standard Linux suggestion BTW, not my idea.) NB, we're not talking about protocols or PPIs (they're ABI); this is about (statically linked) edk2-only libraries. Thanks! Laszlo > > -Jordan > >> I think it makes total sense to turn on DISABLE_DEPRECATED_INTERFACES on >> all the open source edk2 platform as soon as possible so all the open >> source code is following current best practices. >> Not to mention it would probably be a really good idea to give all the >> downstream folks a long lead time about the plan of making a non backward >> compatible change. >> Thanks, >> Andrew Fish >> >> -Jordan >> >> Before making any such changes, I would like a strong commitment from >> other package owners that deprecating an interface brings along with >> it the responsibility to update all existing callers, otherwise >> setting this define will only result in more breakage, and ARM has >> seen its share of inadvertent breakage in the past when changes to >> core code were made without taking other architectures into account. >> >> On 21 October 2016 at 02:21, >> wrote: >> >> https://bugzilla.tianocore.org/show_bug.cgi?id=164 >> >> yonghong.zhu@intel.com changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> Priority|Lowest |Normal >> Status|UNCONFIRMED |CONFIRMED >> Assignee|michael.d.kinney@intel.com >> |ard.biesheuvel@linaro.org >> Ever confirmed|0 |1 >> Release(s) the| |EDK II Trunk >> issues must be| | >> fixed| | >> >> --- Comment #1 from yonghong.zhu@intel.com --- >> Assign to Package owner. >> >> -- >> You are receiving this mail because: >> You are the assignee for the bug. >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel