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 <[email protected]> >> 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, <[email protected]> >> wrote: >> >> https://bugzilla.tianocore.org/show_bug.cgi?id=164 >> >> [email protected] changed: >> >> What |Removed |Added >> >> ---------------------------------------------------------------------------- >> Priority|Lowest |Normal >> Status|UNCONFIRMED |CONFIRMED >> Assignee|[email protected] >> |[email protected] >> Ever confirmed|0 |1 >> Release(s) the| |EDK II Trunk >> issues must be| | >> fixed| | >> >> --- Comment #1 from [email protected] --- >> Assign to Package owner. >> >> -- >> You are receiving this mail because: >> You are the assignee for the bug. >> >> _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
