On 07/15/15 10:59, Ard Biesheuvel wrote: > On 15 July 2015 at 08:26, Gao, Liming <liming....@intel.com> wrote: >> Ard:
>> From compatible view, I don't prefer to make this change. The >> driver in other EDKII package may use this PCD. After this change, >> they will build break. >> >> I suggest to keep this PCD, and update its comment to include new >> type. Its comment can highlight this type is not defined in UEFI >> specification. >> > > OK, that is also fine, I obviously accept the above decision, but it should be noted that this makes MdePkg practically unmodifiable. Normally a contributor takes care to modify not just a declaration of "something", but to bring in sync *all* uses of the declaration too. However, that's only possible for such uses that the contributor can *see*. If everything in MdePkg must be preserved as-is, forever, for the sake of forks (proprietary or otherwise -- simply stuff that depends on the declarations but exists out of tree), then that quite guarantees that MdePkg will grow layers and layers of cruft over time. The Linux kernel doesn't guarantee any API stability for out-of-tree code. But, all in-tree code is carefully adapted when APIs change. On the other hand, for example, Red Hat guarantees some level of kernel ABI stability. (Google "Red Hat KABI whitelist".) Occasionally it does come at a hefty price with regard to code clarity in the Red Hat kernels -- sometimes keeping ABI stability requires elaborate, crufty detours in code. While that makes sense for a commercial downstream, in *upstream* edk2 I don't think it's a very friendly (or clear-cut!) rule / limitation for contributors. At least Red Hat *clearly* defines "separation points" in the release cycle across which the kernel ABI stability is *not* guaranteed -- and then we can shed the cruft. Clear rules for MdePkg, MdeModulePkg, etc (as to when compat stuff can be phased out) would be helpful. Anyway, I do accept the decision; I just had to say my piece. Thanks Laszlo > > Thanks, > Ard. > > >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Tuesday, July 14, 2015 6:36 PM >> To: edk2-devel@lists.sourceforge.net; heyi....@linaro.org; >> ler...@redhat.com; Tian, Feng; Gao, Liming >> Cc: roy.fr...@linaro.org; Ard Biesheuvel >> Subject: [PATCH 2/2] MdePkg: remove PcdDefaultTerminalType >> >> The PCD gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType is not used anywhere >> in MdePkg itself, and with the introduction of TTYTERM, it may now assume >> values that are not defined in MdePkg either. >> >> So now that we moved it to MdeModulePkg, remove this one that is now unused. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> >> --- >> MdePkg/MdePkg.dec | 9 --------- >> 1 file changed, 9 deletions(-) >> >> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index >> bda6550ed6c6..026a94987bef 100644 >> --- a/MdePkg/MdePkg.dec >> +++ b/MdePkg/MdePkg.dec >> @@ -2007,15 +2007,6 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, >> PcdsDynamic, PcdsDynamicEx] >> # @ValidRange 0x80000001 | 0 - 3 >> gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits|1|UINT8|0x00000023 >> >> - ## Indicates the usable type of terminal.<BR><BR> >> - # 0 - PCANSI<BR> >> - # 1 - VT100<BR> >> - # 2 - VT100+<BR> >> - # 3 - UTF8<BR> >> - # @Prompt Default Terminal Type. >> - # @ValidRange 0x80000001 | 0 - 3 >> - gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x00000024 >> - >> ## Error level for hardware recorder. >> # If value 0, platform does not support feature of hardware error record. >> # @Prompt Error Level For Hardware Recorder >> -- >> 1.9.1 >> ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
