On 11/22/18 07:14, Gao, Liming wrote:
> Siyuan:
> Thanks for your contribution. I really like this idea to share the
> common DSC/FDF between all platform DSC/FDFs. Now, FixedAtBuild PCD
> can also be used in the conditional statement. Its value can be
> specified by build command with --pcd option. So, I suggest to use
> FixedAtBuild PCD for network feature instead of MACRO. I would like
> to recommend to use PCD both for the build and firmware
> configuration. For this case, one UINT16 FixedAtBuildPcd can be
> introduced in NetworkPkg.dec. Its different bit will be for the
> different network features. Below is the example.
I disagree.
A bitmask is a very good representation for *computers*, to handle a set
of features. On the other hand, a bitmask is a catastrophically bad
representation for *humans*, when they are trying to configure a
platform build (that is, writing a build command line), selecting the
firmware features they want. It is hard to compute, and it is extremely
hard to grep for.
It is trivial to grep a build script for "NETWORK_TLS_ENABLE". It is
much harder to grep the same script for PcdNetworkFeatureMask, and then
check whether bit#4 is set in the value.
> Besides, I think *.dsc.inc files need to include section header. If
> so, *.dsc.inc is the standalone dsc file. It can easily be included in
> platform DSC file.
I disagree. For a platform, spelling out the section header is not a big
burden, but it provides a lot of flexibility. For example, it can
restrict the scope of the included text (e.g., component list) to a
specific architecture only. For another example, the platform's section
header can specify the flavor of the PCDs for which the included text
provides the default values (fixed PCD, patchable PCD, even dynamic(ex)
PCD).
Standalone DSC file is the wrong thing to aim for, in this instance --
in my opinion anyway. Yes, it appears simpler, but it loses too much
flexibility. In my earlier comments I pointed out that the "allow
plaintext HTTP connections" PCD was declared in NetworkPkg.dec as either
fixed or patchable. The dsc.inc file should not squander that
flexibility and dictate fixed only.
> Especially for library instance, the different library instance may be
> for the different module type. Without section header, they can be
> placed into one *Libs.dsc.inc file.
Ugh... I'm now condfused. Now it seems that you and I are asking for the
same thing actually. Did you perhaps mean, above, that "*.dsc.inc files
need *NOT* include section header"?
> [Defines]
> DEFINE NETWORK_ENABLE = 0x1
> DEFINE NETWORK_SNP_ENABLE = 0x2
> DEFINE NETWORK_IP4_ENABLE = 0x4
> DEFINE NETWORK_IP6_ENABLE = 0x8
> DEFINE NETWORK_TLS_ENABLE = 0x10
> DEFINE NETWORK_HTTP_BOOT_ENABLE = 0x20
> DEFINE NETWORK_ALLOW_HTTP_CONNECTIONS = 0x40
> DEFINE NETWORK_IPSEC_ENABLE = 0x80
> DEFINE NETWORK_ISCSI_ENABLE = 0x100
> DEFINE NETWORK_VLAN_ENABLE = 0x200
>
> [PcdsFixedAtBuild]
> gEfiNetworkPkgTokenSpaceGuid.PcdNetworkFeatureMask|0xFFFF
>
> [PcdsFixedAtBuild]
> !if gEfiNetworkPkgTokenSpaceGuid.PcdNetworkFeatureMask &
> NETWORK_ALLOW_HTTP_CONNECTIONS == NETWORK_ALLOW_HTTP_CONNECTIONS
> gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
> !endif
Sure, this looks good in the DSC include file, but it looks very bad on
the build command line. Compare:
build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -t GCC48 -b NOOPT \
-D SECURE_BOOT_ENABLE -D SMM_REQUIRE \
-D NETWORK_ENABLE -D NETWORK_IP4_ENABLE \
-D NETWORK_HTTP_BOOT_ENABLE -D NETWORK_TLS_ENABLE
versus
build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -t GCC48 -b NOOPT \
-D SECURE_BOOT_ENABLE -D SMM_REQUIRE \
--pcd gEfiNetworkPkgTokenSpaceGuid.PcdNetworkFeatureMask=0x0035
First, composing the second command line takes at least four times as
long for me (calculating the value 0x35). Second, while
grep NETWORK_IP4_ENABLE
will easily match the first command (in a shell script or similar), the
same search would require an awkward, ad-hoc parser for matching the
second command.
Thanks
Laszlo
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu
>> Siyuan
>> Sent: Thursday, November 22, 2018 1:22 PM
>> To: edk2-devel@lists.01.org
>> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Ye, Ting <ting...@intel.com>; Justen,
>> Jordan L <jordan.l.jus...@intel.com>; Wu, Hao A <hao.a...@intel.com>; Wu,
>> Jiaxin <jiaxin...@intel.com>; Anthony Perard <anthony.per...@citrix.com>;
>> Laszlo Ersek <ler...@redhat.com>; Wei, David <david....@intel.com>
>> Subject: [edk2] [PATCH v2 0/6] Add DSC/FDF include segment files for
>> network stack
>>
>> There is a patch to remove the redudant IP4 only iSCSI/PXE/TCP drivers
>>from MdeModulePkg, which has been reviewed before edk2-stable201811
>> tag.
>> And we also have plan to move all network related libraries/modules to
>> NetworkPkg. In order to make these change more smoothly, a set of
>> fragment
>> files (2 for DSC and 1 for FDF) are provided for platform to enable the
>> network stack support, without directly reference the INF module path.
>>
>> Patch 1/6 adds centralized dsc/fdf include files to NetworkPkg, with
>> a set of flags for feature set enable/disable.
>> Patch 2~6 updates edk2 platform dsc/fdf files to use the new include
>> files, instead of reference the module INF.
>>
>> v2:
>> 1. Split the "Network.dsc.inc" in to 4 files for different sections in DSC
>> file. This could provide more flexibility to platform owner to use the
>> include files.
>> 2. Clarify the OpenSSL dependency of TLS, iSCSI and IPsec enable flag.
>> 3. Use "!error" statement for incorrect flag value check.
>> 4. Update platform DSC/FDF to use the new include files.
>> 5. Other decoration work according to Laszlo's comments.
>>
>>
>>
>> Fu Siyuan (6):
>> NetworkPkg: Add DSC/FDF include segment files to NetworkPkg.
>> Nt32Pkg: Update DSC/FDF to use NetworkPkg's include fragment file.
>> ArmVirtPkg: Update DSC/FDF to use NetworkPkg's include fragment file.
>> EmulatorPkg: Update DSC/FDF to use NetworkPkg's include fragment file.
>> OvmfPkg: Update DSC/FDF to use NetworkPkg's include fragment file.
>> Vlv2TbltDevicePkg: Update DSC/FDF to use NetworkPkg's include fragment
>> file.
>>
>> ArmVirtPkg/ArmVirt.dsc.inc | 11 +-
>> ArmVirtPkg/ArmVirtQemu.dsc | 46 ++-----
>> ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 28 +---
>> ArmVirtPkg/ArmVirtQemuKernel.dsc | 46 ++-----
>> EmulatorPkg/EmulatorPkg.dsc | 39 ++++--
>> EmulatorPkg/EmulatorPkg.fdf | 10 +-
>> NetworkPkg/Network.fdf.inc | 69 ++++++++++
>> NetworkPkg/NetworkComponents.dsc.inc | 71 ++++++++++
>> NetworkPkg/NetworkDefines.dsc.inc | 138 ++++++++++++++++++++
>> NetworkPkg/NetworkLibs.dsc.inc | 25 ++++
>> NetworkPkg/NetworkPcds.dsc.inc | 22 ++++
>> NetworkPkg/NetworkPkg.dsc | 28 +---
>> Nt32Pkg/Nt32Pkg.dsc | 104 ++++-----------
>> Nt32Pkg/Nt32Pkg.fdf | 27 +---
>> OvmfPkg/OvmfPkgIa32.dsc | 75 +++++------
>> OvmfPkg/OvmfPkgIa32.fdf | 27 +---
>> OvmfPkg/OvmfPkgIa32X64.dsc | 76 +++++------
>> OvmfPkg/OvmfPkgIa32X64.fdf | 27 +---
>> OvmfPkg/OvmfPkgX64.dsc | 75 +++++------
>> OvmfPkg/OvmfPkgX64.fdf | 27 +---
>> Vlv2TbltDevicePkg/PlatformPkg.fdf | 25 +---
>> Vlv2TbltDevicePkg/PlatformPkgConfig.dsc | 11 +-
>> Vlv2TbltDevicePkg/PlatformPkgGcc.fdf | 25 +---
>> Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 52 +++-----
>> Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 52 +++-----
>> Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 52 +++-----
>> 26 files changed, 573 insertions(+), 615 deletions(-)
>> create mode 100644 NetworkPkg/Network.fdf.inc
>> create mode 100644 NetworkPkg/NetworkComponents.dsc.inc
>> create mode 100644 NetworkPkg/NetworkDefines.dsc.inc
>> create mode 100644 NetworkPkg/NetworkLibs.dsc.inc
>> create mode 100644 NetworkPkg/NetworkPcds.dsc.inc
>>
>> Cc: Jiaxin Wu <jiaxin...@intel.com>
>> Cc: Ting Ye <ting...@intel.com>
>> Cc: Ruiyu Ni <ruiyu...@intel.com>
>> Cc: Hao Wu <hao.a...@intel.com>
>> Cc: Laszlo Ersek <ler...@redhat.com>
>> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Cc: Julien Grall <julien.gr...@linaro.org>
>> Cc: Jordan Justen <jordan.l.jus...@intel.com>
>> Cc: Andrew Fish <af...@apple.com>
>> Cc: Ruiyu Ni <ruiyu...@intel.com>
>> Cc: Anthony Perard <anthony.per...@citrix.com>
>> Cc: David Wei <david....@intel.com>
>> Cc: Mang Guo <mang....@intel.com>
>>
>> --
>> 2.19.1.windows.1
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
