From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by mx.groups.io with SMTP id smtpd.web10.5824.1585745715633076170 for ; Wed, 01 Apr 2020 05:55:15 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=0nJGQX8k; spf=pass (domain: nuviainc.com, ip: 209.85.221.68, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f68.google.com with SMTP id w10so30512100wrm.4 for ; Wed, 01 Apr 2020 05:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KBT8XA5T57VkkEH586uqMCs+X8w3N89H4MpZI3WGlxs=; b=0nJGQX8kkYj3TVXHqdE//0X5oYTLOCNOX7WgblHhz0sFV1pMRS/jyGths5vk/OEm1V mLe5ukNG7VQzHRj754OCixDGvSIok2od9U+VaOVnjh4vXgKjGaAfsUsCmMT+ceZ1LSdr og9yHmgnZgpHYL4yv40ysnUyFW9U07Ov/p+MnZcque4jBiUSqsEJuQd/Z6bfdcyAx188 6vHrhF5/noFiHDYVvbX2SPUVkQgmLAxCB37LCJYysNrBjOHndZ35r1X4CGrgtP1y/wQ7 kY7Io+ZgX1V81NzQd+BifQ2eIK5aAPanQfYp8tZ8dXdhFN8leOlHrtSh8eDDyiwFoA/F Gxqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KBT8XA5T57VkkEH586uqMCs+X8w3N89H4MpZI3WGlxs=; b=LqZ9ILDbjeTIHRHp3+uueR6Lpue6epKAqKzE2f2pbljCpypJkj17hcEefwX3vOsmHu IOyqIvhTMTyZ6JgkJa70AYwSlycHY8amrvQ0nP+ere7rGfuN+Md+nSh062yxMAMJd23t I1L7FloVSjatfCLa3oDfT9is5AhbVPrZMJJlvMP0sL2Vn5ukJr02sSWB6TGPv0DiKnr9 rrCMtQm/5g50HC3xdShIQoW7Zieo2FNEXZgt6ywifFBGFkHibTOI5eSdmpY+1JGGc1bc J2kBbUQgeKakSMHtayKL0q2efSPGgaP3YROZSkrl3P5xeC7uvsVBzeQKjJun9BdU6R0/ A+RA== X-Gm-Message-State: ANhLgQ3nkJQq+XCoXRLAyr1UAtBbMdBSMZEfIPBLfrXIN7KUCVAtlq9r PcIqtV/PQEKk95M6Bd+gVM23IQ== X-Google-Smtp-Source: ADFU+vt21NuYT0jc6tsuNtbVTonrmUEzgOzV94Q3pRwuZ9N9Hp2Th0AIEesvXAEDcsZG88nVu7u6tg== X-Received: by 2002:adf:97d0:: with SMTP id t16mr25893093wrb.343.1585745714155; Wed, 01 Apr 2020 05:55:14 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id p10sm2884773wrm.6.2020.04.01.05.55.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2020 05:55:13 -0700 (PDT) Date: Wed, 1 Apr 2020 13:55:11 +0100 From: "Leif Lindholm" To: Laszlo Ersek Cc: "Ni, Ray" , Ard Biesheuvel , "Jiang, Guomin" , "devel@edk2.groups.io" , Andrew Fish , Michael D Kinney Subject: Re: [edk2-devel] API breakages and their implications. Was: [PATCH 1/1] MdeModulePkg: UART Dynamic clock freq Support Message-ID: <20200401125511.GZ7468@vanye> References: <20200319153057.GV23627@bivouac.eciton.net> <20200330073518.GU22097@bivouac.eciton.net> <734D49CCEBEEF84792F5B80ED585239D5C4CD51C@SHSMSX104.ccr.corp.intel.com> <20200331092226.GB7468@vanye> <2bb24cc3-96d1-5e37-b069-f009cf824aef@redhat.com> MIME-Version: 1.0 In-Reply-To: <2bb24cc3-96d1-5e37-b069-f009cf824aef@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 31, 2020 at 15:23:24 +0200, Laszlo Ersek wrote: > On 03/31/20 11:22, Leif Lindholm wrote: > > "This breaks many platforms" is a good argument for seeing if a > > solution can be found that does not break (as) many platforms. It is > > not an argument for duplicating drivers when the change needed for > > those platforms is trivial. > > > > These days, Linux tends to deal with API breakages (and other things) > > using a semantic patch tool called Coccinelle[1]. It would not be > > unreasonable, and indeed it would be helpful to us on the non-x86 side > > if something similar was adopted (and semantic patches mandated) for > > API breakages in EDK2. > > > > [1] http://coccinelle.lip6.fr/sp.php > > Two comments: > > (1) One of the reasons why I would like to keep all platforms in a > single tree is to deal with API changes like this. Agreed. > That way, someone > proposing an API change would at least have the chance to fix up all the > consumer sites. Of course it would require diligent review from the > other pkg maintainers, but it could be implemented without any temprary > breakage in the git history even. And a daily CI job could spot breakages and send out alerts to platform owners. It would also provide more incentive for actually upstreaming platform ports. > (2) Specifically about this problem. The vendor GUID approach is not a > bad one. How about the following alternative: I have no strong comment on your alternative. It seems perfectly feasible, and I agree there is precedent. Thanks for providing it. I will let the MdeModulePkg maintainers specify their preference, or provide other alternative solutions. Best Regards, Leif