On 10/21/16 22:19, Ard Biesheuvel wrote: > On 21 October 2016 at 21:14, Laszlo Ersek <[email protected]> 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
