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! :) -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
