public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	Vitaly Cheptsov <cheptsov@ispras.ru>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Andrew Fish" <afish@apple.com>,
	"Marvin Häuser" <mhaeuser@outlook.de>,
	"Gao, Liming" <liming.gao@intel.com>,
	"Gao, Zhichao" <zhichao.gao@intel.com>
Subject: Re: [PATCH V4 00/27] Disabling safe string constraint assertions
Date: Tue, 12 May 2020 11:50:43 +0200	[thread overview]
Message-ID: <44ac1ca1-953a-21a2-0c9e-c83aca153b0b@redhat.com> (raw)
In-Reply-To: <MN2PR11MB446155752A1BB7EADB0F8F69D2A10@MN2PR11MB4461.namprd11.prod.outlook.com>

On 05/12/20 00:40, Kinney, Michael D wrote:
> Vitaly,
> 
> Thank you for the contribution.
> 
> There are a couple points about this approach that need to be discussed.
> 
> You have included the <Library/DebugCommonLib.h> from 
> MdePkg/Include/Library/DebugLib.h.

Right, I've noticed it. I agree it's unusual. I didn't think it was wrong.

> It is very rare for a 
> lib class to include another lib class.  This means that a module
> that has a dependency on the DebugLib class inherits a hidden
> dependency on the DebugCommonLib class.

I agree.

I think it should be fine. Any header H1 should include such further
headers H2, H3, ... Hn that are required for making the interfaces
declared in H1 usable in client modules.

> For module INF files,
> we require the INF file to list all the lib classes that the
> module sources directly use.

Yes, keyword being "directly".

> Since a module that uses the
> DebugLib uses the ASSERT() and DEBUG() macros, all the APIs
> that the ASSERT() and DEBUG() macros use are also directly
> used by the module.

I believe this is where I disagree. The replacement texts of the
ASSERT() and DEBUG() function-like macros are internals of the
DebugLib.h lib class header, in my opinion. Those internals place
requirements on specific DebugLib instances, not on DebugLib class
consumers.

In other words, when writing a new DebugLib instance, the implementor
has to ensure that the ASSERT() and DEBUG() macros, as defined in the
DebugLib class header, will continue working in DebugLib consumer
modules. The implementor may then choose to make the new DebugLib
instance dependent on the (singleton) DebugCommonLib instance, for
example. (This is being done in patches #3, #4, #16, maybe more.) The
DebugLib consumer module will inherit that dependency, and everything
will work.

Just because ASSERT() and DEBUG() are function-like macros and not
actual functions, I don't think the INF file requirements in
DebugLib-consumer modules should change.

> With this patch series, these macros
> now use the DebugCommonLib class APIs, which means any module
> that uses the DebugLib also directly uses the DebugCommonLib.

In my opinion: indirectly.

Thanks,
Laszlo


  reply	other threads:[~2020-05-12  9:50 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11 15:40 [PATCH V4 00/27] Disabling safe string constraint assertions Vitaly Cheptsov
2020-05-11 15:40 ` [PATCH V4 01/27] MdePkg: Introduce DebugCommonLib interface and BaseDebugCommonLib Vitaly Cheptsov
2020-05-11 20:37   ` [edk2-devel] " Laszlo Ersek
2020-05-11 20:42   ` Laszlo Ersek
2020-05-11 15:40 ` [PATCH V4 02/27] UnitTestFrameworkPkg: Add support for DebugCommonLib Vitaly Cheptsov
2020-05-11 15:40 ` [PATCH V4 03/27] MdePkg: " Vitaly Cheptsov
2020-05-11 15:40 ` [PATCH V4 04/27] MdeModulePkg: " Vitaly Cheptsov
2020-05-11 15:40 ` [PATCH V4 05/27] ArmPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 06/27] ArmPlatformPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 07/27] ArmVirtPkg: " Vitaly Cheptsov
2020-05-11 20:42   ` [edk2-devel] " Laszlo Ersek
2020-05-11 15:41 ` [PATCH V4 08/27] CryptoPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 09/27] DynamicTablesPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 10/27] EmbeddedPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 11/27] EmulatorPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 12/27] FatPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 13/27] FmpDevicePkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 14/27] IntelFsp2Pkg: " Vitaly Cheptsov
2020-05-12  0:49   ` [edk2-devel] " Chiu, Chasel
2020-05-11 15:41 ` [PATCH V4 15/27] IntelFsp2WrapperPkg: " Vitaly Cheptsov
2020-05-12  0:47   ` [edk2-devel] " Chiu, Chasel
2020-05-11 15:41 ` [PATCH V4 16/27] OvmfPkg: " Vitaly Cheptsov
2020-05-11 20:49   ` [edk2-devel] " Laszlo Ersek
2020-05-11 15:41 ` [PATCH V4 17/27] NetworkPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 18/27] ShellPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 19/27] SecurityPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 20/27] PcAtChipsetPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 21/27] SignedCapsulePkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 22/27] SourceLevelDebugPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 23/27] StandaloneMmPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 24/27] UefiCpuPkg: " Vitaly Cheptsov
2020-05-11 20:52   ` [edk2-devel] " Laszlo Ersek
2020-05-11 15:41 ` [PATCH V4 25/27] UefiPayloadPkg: " Vitaly Cheptsov
2020-05-11 15:41 ` [PATCH V4 26/27] MdePkg: Introduce assertion on constraint debug mask bit Vitaly Cheptsov
2020-05-11 20:58   ` [edk2-devel] " Laszlo Ersek
2020-05-11 22:12     ` Laszlo Ersek
2020-05-11 15:41 ` [PATCH V4 27/27] MdePkg: Use assertion on constraint violation bit in SafeString Vitaly Cheptsov
2020-05-11 21:04   ` [edk2-devel] " Laszlo Ersek
2020-05-11 22:40 ` [PATCH V4 00/27] Disabling safe string constraint assertions Michael D Kinney
2020-05-12  9:50   ` Laszlo Ersek [this message]
2020-05-12 17:03     ` Vitaly Cheptsov
2020-05-12 18:18     ` [edk2-devel] " Michael D Kinney
2020-05-12 18:57       ` Vitaly Cheptsov
2020-05-13 17:59         ` Liming Gao
2020-05-13 18:37           ` Vitaly Cheptsov
2020-05-13  9:16       ` Laszlo Ersek
2020-05-13 14:41         ` [EXTERNAL] " Bret Barkelew
2020-05-13 20:14           ` Brian J. Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44ac1ca1-953a-21a2-0c9e-c83aca153b0b@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox