From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by mx.groups.io with SMTP id smtpd.web12.8143.1585659585522413474 for ; Tue, 31 Mar 2020 05:59:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=1JItsN+A; spf=pass (domain: nuviainc.com, ip: 209.85.221.66, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f66.google.com with SMTP id h9so25781744wrc.8 for ; Tue, 31 Mar 2020 05:59:45 -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:content-transfer-encoding:in-reply-to :user-agent; bh=V4Li3gnKCkZwMonQKN8cU+WYAmzE/6UiH/rpSbFYF20=; b=1JItsN+AodI1fcNiRypRl3+2wzgrnIfhl8H7KKTFSv8dFf7xYDdFbwdVJrTdJj2tSG ZlI4T7xzeHK3i8IqwvNSwCI2yiVwW6/d9Dz+cLg/DHDF/9SHhaPvgp6E5ETuuswTskwx R/f8Rx8vgZZLeY+gO92YTm+T+XceEqrFyfFdPyMpftUYcMMAueq/1yZTEGT9TBCdQCDd m43/RoGFyFxXqZ4EwQt2rBEq306V8BJBeNH3F5+eWAq3cy9SRowcURQcqZg9eabvY5KI RYx5n6XICbgUrKtf88ba5oJi0R4K9eldy3gMMo5FMg+5KotyLoiP08K5/YyPUA9ye6UE K6fw== 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:content-transfer-encoding :in-reply-to:user-agent; bh=V4Li3gnKCkZwMonQKN8cU+WYAmzE/6UiH/rpSbFYF20=; b=kje8QktQ13WJsWhYrVmBbDsJQRHAKftb0QBt//TuG4LGy+v7c4J4ZvXA3jgr4NKovx M9RAsgelHvav7xBpWSyaWbgEIAT1gayzeTIHEHy8P2Y2cTVvsX8JrzKLbxEj6V8eP8X7 ZhQF7hSJf44hpH13bINKapcHqw1Cnk4D7WaMVVxPS+sjsolAh6g0MN9zk5Mq0d5v1uUL q2JmXhE7lOYtgacUg01cMguwaUjAnnHXrT3OyQ1ZsF5GNBDoNt2ihI5WGhDtU49pXdmZ FxNM2JDjxpML1O4P777wRPjHfLYp7XX4NdJteFgcEpZXJVSPA0zhU3Y9rvk8d1DalW56 mDtQ== X-Gm-Message-State: ANhLgQ31+vBUZJXUvtcy7soY0+/I3cCtCEnUuG6aJvmkDnIaC2aBNP/z 8udCae7Zegz5zeZ+Zqc/6LN1SQ== X-Google-Smtp-Source: ADFU+vtTjObfP+0S94wYFxegtPpO78WIFCoopOg3Rdax2vrAZZC4Z22CNLm16oXnrik1xbj4voRVYA== X-Received: by 2002:a05:6000:10d1:: with SMTP id b17mr21459995wrx.360.1585659584037; Tue, 31 Mar 2020 05:59:44 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id l12sm26073415wrt.73.2020.03.31.05.59.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2020 05:59:43 -0700 (PDT) Date: Tue, 31 Mar 2020 13:59:41 +0100 From: "Leif Lindholm" To: "Ni, Ray" Cc: Ard Biesheuvel , "Jiang, Guomin" , "devel@edk2.groups.io" , Andrew Fish , Laszlo Ersek , "Kinney, Michael D" Subject: Re: [edk2-devel] API breakages and their implications. Was: [PATCH 1/1] MdeModulePkg: UART Dynamic clock freq Support Message-ID: <20200331125941.GI7468@vanye> References: <20200319153057.GV23627@bivouac.eciton.net> <20200330073518.GU22097@bivouac.eciton.net> <734D49CCEBEEF84792F5B80ED585239D5C4CD51C@SHSMSX104.ccr.corp.intel.com> <20200331092226.GB7468@vanye> <734D49CCEBEEF84792F5B80ED585239D5C4D2131@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C4D2131@SHSMSX104.ccr.corp.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi Ray, I think it's good to start doing it voluntarily, or for changes expected to affect many platforms. Over time, as people become more familiar with the tool, it would make sense to make it first recommended and then mandatory. For Linux, the coccinelle diff is frequently included in the commit message, or (especially when used for changing deprecated interfaces or poor coding practice) they are copmmitted to the repository (under scripts/coccinelle). Regards, Leif On Tue, Mar 31, 2020 at 12:11:03 +0000, Ni, Ray wrote: > Leif, > Thanks for introducing such an interesting tool. > I see this too is very useful for code refactoring. > It's a game changing tool😊 > > To help me understand, do you suggest MAYBE when incompatible changes like this > happen, the change owners propose the semantic patches for all platforms? > > > Thanks, > Ray > > > > -----Original Message----- > > From: Leif Lindholm > > Sent: Tuesday, March 31, 2020 5:22 PM > > To: Ni, Ray > > Cc: Ard Biesheuvel ; Jiang, Guomin ; devel@edk2.groups.io; Andrew > > Fish ; Laszlo Ersek ; Kinney, Michael D > > Subject: Re: [edk2-devel] API breakages and their implications. Was: [PATCH 1/1] MdeModulePkg: UART Dynamic clock freq > > Support > > > > On Tue, Mar 31, 2020 at 01:53:21 +0000, Ni, Ray wrote: > > > Leif, > > > Please understand that the concern of this change is all the platforms that uses > > > this serial port lib must be changed otherwise build breaks. > > > > Yes. This is the nature of collaborative development. > > This is something we on the ARM side have lived with since we got > > involved with EDK2, being the less-deployed user of the codebase, and > > that is fine. > > > > TianoCore specifically produced the UDK to make life easier for those > > who are unable to track upstream, and we have followed that up with > > stable tags. I would highly recommend that any team that feels that > > this change would be too much effort to move to edk2-stable202002. Of > > course, they would then need to manually cherry-pick any improvements > > and security fixes from master. That is their choice. > > > > Nevertheless, breaking existing platforms is a side effect, not a > > goal. So if an alternative solution can be found (which is not a hack > > that is going to affect the codebase negatively over time and simply > > need to be fixed properly at a later date), then clearly that is > > preferable. > > > > "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 > > > > Regards, > > > > Leif > > > > > Ard, > > > Using Guided HOB sounds a good idea to me: ) > > > The benefits of using HOB is: > > > Length field in the HOB header can be used for extension if more parameters are needed. > > > DXE can have the HOB access as well. > > > > > > EFI_SEC_HOB_DATA_PPI can be used to return the new Guided HOB from SEC phase if needed. > > > > > > Thanks, > > > Ray > > > > > > > > > > -----Original Message----- > > > > From: Ard Biesheuvel > > > > Sent: Monday, March 30, 2020 3:45 PM > > > > To: Leif Lindholm > > > > Cc: Jiang, Guomin ; devel@edk2.groups.io; pankaj.bansal@nxp.com; Ni, Ray > > ; > > > > Wang, Jian J ; Wu, Hao A ; Ma, Maurice ; Dong, > > > > Guo ; You, Benjamin ; Meenakshi Aggarwal > > > > ; Varun Sethi ; Samer El-Haj-Mahmoud > > > Mahmoud@arm.com> > > > > Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: UART Dynamic clock freq Support > > > > > > > > On Mon, 30 Mar 2020 at 09:35, Leif Lindholm wrote: > > > > > > > > > > Hi Jiang, > > > > > > > > > > It is not a question of effort of copying a driver, it is a question > > > > > that copying drivers is something that should be avoided wherever > > > > > practically possible. I did not think this topic was still under > > > > > debate. > > > > > > > > > > If the existing 16550 SerialPortLib is overspecialised to the point > > > > > where it only works on a subset of 16550 implementations, then it > > > > > should change. There are going to be more non-PC systems turning up > > > > > with 16550 UARTs - should they each copy/modify their drivers? > > > > > > > > > > If there are better ways of solving that problem, please suggest. > > > > > But more duplicated drivers is not the answer. > > > > > > > > > > > > > Could we use a GUIDed HOB? If it exists, we use its contents, and if > > > > it doesn't, we use the default set by the FixedPCD.