From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "Zeng, Star" <star.zeng@intel.com>, Hao Wu <hao.a.wu@intel.com>,
Michael D Kinney <michael.d.kinney@intel.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
Liming Gao <liming.gao@intel.com>
Subject: Re: [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version
Date: Thu, 10 Jan 2019 17:23:24 +0100 [thread overview]
Message-ID: <CAKv+Gu9Qyix9YGhL-U9_KY-b6=op0r+qaowFvNLo7Vz1JSU=9g@mail.gmail.com> (raw)
In-Reply-To: <91581880-e3ef-31d6-40eb-1d52f5f0cdc1@redhat.com>
On Thu, 10 Jan 2019 at 14:03, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 01/10/19 08:59, Zeng, Star wrote:
> > On 2019/1/10 15:33, Ard Biesheuvel wrote:
> >> On Thu, 10 Jan 2019 at 08:30, Zeng, Star <star.zeng@intel.com> wrote:
> >>>
> >>> Hi Ard,
> >>>
> >>> Another minor feedback.
> >>>
> >>> On 2019/1/10 14:47, Zeng, Star wrote:
> >>>> Hi Ard,
> >>>>
> >>>> Some minor feedback added inline.
> >>>>
> >>>> On 2019/1/4 2:28, Ard Biesheuvel wrote:
> >>>>> Implement a new version of the fault tolerant write driver that can
> >>>>> be used in the context of a standalone MM implementation.
> >>>>>
> >>>>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >>>>> ---
> >>>>>
> >>>>> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
> >>>>>
> >>>>> | 70 +++++++++++++++
> >>>>>
> >>>>> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> >>>>>
> >>>>> | 90 ++++++++++++++++++++
> >>>>> 2 files changed, 160 insertions(+)
> >>>
> >>> Please add it into MdeModulePkg.dsc for package build verification.
> >>>
> >>
> >> Hello Star,
> >>
> >> Thanks for all the feedback. I will respond in more detail later.
> >>
> >> However, to the point raised here: it is not possible to add these
> >> drivers to MdeModulePkg.dsc unless we add a dummy implementation of
> >> StandaloneMmDriverEntryPoint to MdeModulePkg. Do you think we should
> >> do that?
> >
> > Oh, good information.
> > To have full code building coverage for the package, personally I think
> > we can move StandaloneMmDriverEntryPoint library class and instance into
> > MdePkg, and even the MmServicesTableLib for MM_STANDALONE, they should
> > be generic enough.
> >
> > I do not want to block this patch set because of this. So let's discuss
> > this in parallel as separated topic.
> >
> > Mike, Liming, Laszlo, Jian and Hao,\
> > What's your opinion?
>
> It should be possible to build all library instances in a central
> Package (well, all Packages really), using the Package's DSC file. To my
> understanding, libraries built like this are not expected to be used in
> actual (shipped) drivers / applications, nor is their indiscriminate
> distribution (as LIBs) expected. For example, shipping a BaseXxxLibNull
> library instance in binary form seems quite useless.
>
> With that in mind, I think a Null instance for the entry point in
> question makes sense, under MdeModulePkg.
>
I will look into this a bit deeper next week. I think it makes sense
for the core PI architected pieces to all live in MdePkg rather than
StandaloneMmPkg. For instance, MmServicesTableLib for standalone MM
should live there, MmEntryPoint should live there (and have
traditional and standalone MM implementation) and perhaps some other
core pieces as well.
This may be a slippery slope, so I will dedicate some time to look
into this carefully, at least with the goal to make the
FaultTolerantWrite and Variable driver buildable from within
MdeModulePkg.
next prev parent reply other threads:[~2019-01-10 16:23 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 18:28 [PATCH 0/6] implement standalone MM versions of the variable runtime drivers Ard Biesheuvel
2019-01-03 18:28 ` [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries Ard Biesheuvel
2019-01-04 5:51 ` Feng, Bob C
2019-01-03 18:28 ` [PATCH 1/6] MdePkg/Include: add MmServicesTableLib header file Ard Biesheuvel
2019-01-10 6:06 ` Zeng, Star
2019-01-03 18:28 ` [PATCH 2/6] MdePkg: implement MmServicesTableLib based on traditional SMM Ard Biesheuvel
2019-01-10 1:35 ` Wang, Jian J
[not found] ` <9bfb4d7c-3d4e-c05c-49a1-1959ddc902e3@intel.com>
2019-01-10 6:54 ` Zeng, Star
2019-01-03 18:28 ` [PATCH 3/6] MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses Ard Biesheuvel
2019-01-10 1:36 ` Wang, Jian J
2019-01-10 6:45 ` Zeng, Star
2019-01-03 18:28 ` [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version Ard Biesheuvel
2019-01-10 1:41 ` Wang, Jian J
2019-01-10 1:48 ` Wang, Jian J
2019-01-10 6:31 ` Zeng, Star
2019-01-10 6:47 ` Zeng, Star
2019-01-10 7:29 ` Zeng, Star
2019-01-10 7:33 ` Ard Biesheuvel
2019-01-10 7:59 ` Zeng, Star
2019-01-10 12:28 ` Wang, Jian J
2019-01-10 13:03 ` Laszlo Ersek
2019-01-10 16:23 ` Ard Biesheuvel [this message]
2019-01-11 2:18 ` Zeng, Star
2019-01-03 18:28 ` [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses Ard Biesheuvel
2019-01-08 15:38 ` Laszlo Ersek
2019-01-10 2:33 ` Wang, Jian J
2019-01-10 7:17 ` Zeng, Star
2019-01-10 7:19 ` Zeng, Star
2019-01-03 18:28 ` [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement standalone MM version Ard Biesheuvel
2019-01-10 1:49 ` Wang, Jian J
2019-01-10 1:50 ` Wang, Jian J
2019-01-10 7:28 ` Zeng, Star
2019-01-03 19:13 ` [PATCH 0/6] implement standalone MM versions of the variable runtime drivers Ard Biesheuvel
2019-01-07 12:44 ` Gao, Liming
2019-01-07 13:05 ` Ard Biesheuvel
2019-01-07 19:08 ` Laszlo Ersek
2019-01-09 13:56 ` Gao, Liming
2019-01-09 15:29 ` Ard Biesheuvel
2019-01-14 2:55 ` Gao, Liming
2019-01-14 8:26 ` Ard Biesheuvel
2019-01-14 15:33 ` Gao, Liming
2019-01-09 9:44 ` Laszlo Ersek
2019-01-09 10:28 ` Ard Biesheuvel
2019-01-09 15:04 ` Laszlo Ersek
2019-01-09 21:46 ` Laszlo Ersek
2019-01-09 21:56 ` Ard Biesheuvel
2019-01-10 8:24 ` Zeng, Star
2019-01-13 15:42 ` Zeng, Star
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='CAKv+Gu9Qyix9YGhL-U9_KY-b6=op0r+qaowFvNLo7Vz1JSU=9g@mail.gmail.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