public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: valerij zaporogeci <vlrzprgts@gmail.com>
To: edk2-devel <edk2-devel@lists.01.org>
Subject: NotifyPpi description contradiction
Date: Sun, 6 Nov 2016 02:43:13 +0200	[thread overview]
Message-ID: <CANPuzFz1Ycy435V10L+n=7Aa6W7H+XTeFq5e+7htE4-__BVSew@mail.gmail.com> (raw)

Hi.
I have two quotes from Pei spec (Vol1) related to the notification
(callback) invocation logic. Tell me, which one tells the truth. They
are obviously contradictive.
Quote (page 26, description of NotifyPpi service):
Description
This service enables PEIMs to register a given service to be invoked
when another service is
installed or reinstalled. This service will fire notifications on PPIs
installed prior to this service
invocation. This is different behavior than the RegisterProtocolNotify
of UEFI2.0, for example
EFI_PEI_NOTIFY_DESCRIPTOR is defined in “PEIM Descriptors” on page 113.

Quote (page 115-116, EFI_PEI_NOTIFY_DESCRIPTOR description):
Description
EFI_PEI_NOTIFY_DESCRIPTOR is a data structure that is used by a PEIM
that needs to be
called back when a PPI is installed or reinstalled. The notification
is similar to the
RegisterProtocolNotify() function in the UEFI 2.0 Specification.
...
Following is an example of the notification use model for
EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI. In this example, a PEIM called
SamplePeim executes early in the PEI phase before main memory is
available. However,
SamplePeim also needs to create some large data structure later in the
PEI phase. As such,
SamplePeim has a NULL depex, but after its entry point is processed,
it needs to call
NotifyPpi() with a EFI_PEI_NOTIFY_DESCRIPTOR, where the notification descriptor
includes the following:
• A reference to EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI
• A reference to a function within this same PEIM called SampleCallback
When the PEI Foundation finally migrates the system from temporary to
permanent memory and installs the
EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI, the PEI Foundation assesses if
there are any pending notifications on this PPI. After the PEI
Foundation discovers the descriptor from SamplePeim, the PEI
Foundation invokes SampleCallback.

So, when SamplePeim invokes NotifyPpi on
EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI, its callback (SampleCallback)
will be called if EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI is ALREADY
installed at this time, or if EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI
will be installed later, AFTER this notification registration for it
by NotifyPpi?
It's obvious, that the answer is the second variant - when the PPI in
question will be installed AFTER the notification registration on it.
As it is seen on the quoted example. But then, the first quote,
NotifyPpi description, says absolutely opposite and very misleading
thing.
And yet, in light of the above, NotifyPpi description also lacks
explanation how it would behave if a PEIM tries to register a
notification for the PPI already installed. What should happen in this
case? Should Peim's callback still be called (when if so)? Or should
NotifyPpi return an error, or success without any action? I believe,
it should register it and call only for the other later installed
instances with the same GUID. Is it a right guess?
And also, regarding the fact there might be multiple instances of the
particular PPI (with the same Guid). Did I understood properly, that
with this model, since Peim registers for notification by the GUID,
this means that on every instance installation and reinstallation of
the PPI with the same GUID, Peim's callback will and should be called?
Thank you for possible answer.


             reply	other threads:[~2016-11-06  0:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-06  0:43 valerij zaporogeci [this message]
2016-11-07 15:47 ` NotifyPpi description contradiction Laszlo Ersek
2016-11-07 21:04   ` valerij zaporogeci

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='CANPuzFz1Ycy435V10L+n=7Aa6W7H+XTeFq5e+7htE4-__BVSew@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