From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0D9F21A1E28 for ; Fri, 21 Oct 2016 13:57:21 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m138so7969626itm.0 for ; Fri, 21 Oct 2016 13:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C6tg/T08s4pyezD+akMeiVdsWIwa5vlRqYOMX9ZzugI=; b=i0lDqdgG7UAEqBS3MntZpsg/O4r/xByKrSJ6fbMRj4NDERi9SUYd+idsA++TELlKTK 7E3yePFdABzLR5u+uhG0yCjyrKBReJ8rWt0uc0ajqXlY0y6FagYyiRJVcYDJgFb18J2T 7AkTKT/Ya3D0yt4hq1Zo2+gXZLc0WptVeMwug= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C6tg/T08s4pyezD+akMeiVdsWIwa5vlRqYOMX9ZzugI=; b=l2Gi2hDyeaiu/Ih8mQxZjmpc9kEVJVswOA6QDEBGaIeuVyVitfEz3l5r2yXyTlpgA1 ldnIF79H2JMB6dzvCPHNgPgxKOuiYIVB5Ew5stmZpP+qxuLxJPiNXNQXGs18/QHQ6aQ7 DPSf7MT+SVoVFtwlJu93LnbU3D4NUf+hAdE+dZl3me7hxiwXmi2GIUSvc8XuC1H2QVry SSaeDJ9b0E+dW/4MYyR+r1SdhlvI3ALETaifY+S1B0rhtzvBhTtPecDi70w24uoq0Ovh qL1jgAPgjArV/iW6AB4g98P21JmZ58kDnyY1gGsFWk0FQSEXfYM1wNKM6Ew9qEHSza6v g6Uw== X-Gm-Message-State: ABUngvduPpXlcBgenRETirvWNf9BTf6HtzsQE4VzI6vJmpv8lNQWajsD9bsji9/wj9JCsolh0BUvcf0AEw2hKMpJ X-Received: by 10.36.14.145 with SMTP id 139mr369963ite.63.1477083440043; Fri, 21 Oct 2016 13:57:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.5.139 with HTTP; Fri, 21 Oct 2016 13:57:19 -0700 (PDT) In-Reply-To: <878ac061-777d-ec5a-a00b-da84c701cc93@redhat.com> References: <147707992484.13791.10042868456965197315@jljusten-ivb> <878ac061-777d-ec5a-a00b-da84c701cc93@redhat.com> From: Ard Biesheuvel Date: Fri, 21 Oct 2016 21:57:19 +0100 Message-ID: To: Laszlo Ersek Cc: Jordan Justen , edk2-devel-01 , "Kinney, Michael D" , Leif Lindholm , "afish@apple.com" , "Gao, Liming" 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:57:21 -0000 Content-Type: text/plain; charset=UTF-8 On 21 October 2016 at 21:40, Laszlo Ersek wrote: > 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? ;) > Yes it is. But it should be made explicit.