From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 4742F1A1E28 for ; Fri, 21 Oct 2016 13:19:14 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id e187so5285181itc.1 for ; Fri, 21 Oct 2016 13:19:14 -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=crAWYITj+pSvNV0oauk3FmqYKG50Hhe1IbYWSmlAacE=; b=eEhOZuV5wU3OiMjfB3w+RxB2mrD75TH7zxmXzowLYBGd9Xjy0WMFMORqZX8Ox8Luc9 2x0YeYQXHfqmUAwN/MADICB6mx/hqBn+bHtoQjPLw4twQALkSCxuSByNl7AfW77eUKHK eCrFAw6HUDgmIkgTzRJsMq42szi2BNsPovOdU= 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=crAWYITj+pSvNV0oauk3FmqYKG50Hhe1IbYWSmlAacE=; b=CKv3I8Dia9fka41/YwPovaJEr3kNj9kdVHO3TRbOF1FF6L7V0X64+q+jFOXCg3u1oP ozY6itceRcTwDlbglX+ExmlqAOLBpGf1ZW8O+1xqfWmGIJgI6MYiRoJmbY7BDzZENwdx Z0WXBMBffwn3gQy/LRV8Xnm8pvLaN07HQvLnsd20DC8LleT9CmygTMLLkj5PdB2CpMWK ++O67S7ocJoX9pmiROxEXgdVwPbRzQszytyDJdA4niixhZiUfXRMdEwlpapO+XaEyS0S FAbGX5D4RtsyqTPR4YvfyKYsl9K0uK+PhSjTl+ABAsOyQKhKjWaLxEXDFRrAHeGQoBEX yiLw== X-Gm-Message-State: ABUngvdqCIUNMtuDQ6bxvu7p1pjqDL9x+qJacH8hddY9hwjOl9tgutlXkeZsyEMfPCv+yDmk+QKbON6kc+nwF+/Y X-Received: by 10.107.25.11 with SMTP id 11mr2834974ioz.138.1477081153353; Fri, 21 Oct 2016 13:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.5.139 with HTTP; Fri, 21 Oct 2016 13:19:12 -0700 (PDT) In-Reply-To: References: <147707992484.13791.10042868456965197315@jljusten-ivb> From: Ard Biesheuvel Date: Fri, 21 Oct 2016 21:19:12 +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:19:14 -0000 Content-Type: text/plain; charset=UTF-8 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.