Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

2023-11-24 Thread Neal Gompa
On Thu, Nov 2, 2023 at 6:35 AM Laszlo Ersek  wrote:
>
> On 10/31/23 23:27, Jeremy Linton wrote:
> > On 10/31/23 12:37, Neal Gompa via groups.io wrote:
> >> From: Neal Gompa 
> >>
> >> Currently, the ReadyToBoot event is only signaled when a formal Boot
> >> Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
> >>
> >> However, the introduction of Platform Recovery in UEFI 2.5 makes it
> >> necessary to signal ReadyToBoot when a Platform Recovery boot loader
> >> runs because otherwise it may lead to the execution of a boot loader
> >> that has similar requirements to a regular one that is not launched
> >> as a Boot Manager option.
> >>
> >> This is especially critical to ensuring that the graphical console
> >> is actually usable during platform recovery, as some platforms do
> >> rely on the ConsolePrefDxe driver, which only performs console
> >> initialization after ReadyToBoot is triggered.
> >>
> >> This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
> >> in EfiBootManagerProcessLoadOption () when invoking platform recovery,
> >> which is the function that sets up the platform recovery boot process.
> >>
> >> The expected behavior has been clarified in the UEFI 2.10 specification
> >> to explicitly indicate this behavior is required for correct operation.
> >>
> >> This is a rebased version of the patch originally written by Pete Batard.
> >
> > Took me a bit to swap in that whole conversation again, and recheck the
> > spec's and code paths, but this all looks fine to me and should allow
> > the PFTF build to drop the similar patch from Pete that has been carried
> > downstream for the past couple years.
> >
> > As for testing the previous patch has been in the field for a couple
> > years now and i'm not aware of it causing any issues. The additional
> > restriction of limiting it to platform recovery logically makes sense,
> > and as far as I can see shouldn't cause any problems.
> >
> > So,
> >
> > Reviewed-by: Jeremy Linton 
> >
> >
> > As a PS: I also went to check the ready to boot behavior for OsRecovery
> > and realized that apparently none of that support was ever merged?
>
> What else is there, outside of this patch, in need of upstreaming?
>
> > That seems a bit of an oversight since its been in the spec for a few years 
> > now.
>
> "ready-to-boot for OsRecovery" is new in UEFI 2.10 (according to the
> commit message), which is quite recent ("Aug 29, 2022").
>
> I couldn't find the Mantis ticket in the Revision History (for 2.10) though.
>

Is there anything else holding up committing this patch? Jeremy and
you reviewed it earlier in the month...



--
真実はいつも一つ!/ Always, there's only one truth!


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111703): https://edk2.groups.io/g/devel/message/111703
Mute This Topic: https://groups.io/mt/102302654/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc/StdLib: Fixed typo issues in multiple files

2023-11-24 Thread Jayaprakash, N
Reviewed-by : Jayaprakash Nevara 

-Original Message-
From: R, Vishal  
Sent: Friday, November 24, 2023 4:41 PM
To: devel@edk2.groups.io
Cc: R, Vishal ; Rebecca Cran ; Kinney, 
Michael D ; Jayaprakash, N 
Subject: [edk2-libc Patch 1/1] edk2-libc/StdLib: Fixed typo issues in multiple 
files

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4579

This commit fixes the various typo issues found in documentation strings in 
multiple files issue reported via the BZ4579 These changes are documentation 
updates only and does not affect the functionality of the code

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Vishal R 
---
 StdLib/BsdSocketLib/ns_addr.c  |  4 ++--
 StdLib/BsdSocketLib/res_comp.c |  2 +-
 StdLib/BsdSocketLib/res_config.h   |  2 +-
 StdLib/BsdSocketLib/res_init.c |  2 +-
 StdLib/Include/arpa/telnet.h   |  2 +-
 StdLib/Include/errno.h |  2 +-
 StdLib/Include/locale.h|  2 +-
 StdLib/Include/net/if.h|  8 
 StdLib/Include/netns/ns.h  |  2 +-
 StdLib/Include/stdio.h |  2 +-
 StdLib/Include/stdlib.h|  6 +++---
 StdLib/Include/sys/termios.h   | 14 +++---
 StdLib/Include/sys/wait.h  |  2 +-
 StdLib/LibC/Main/Arm/flt_rounds.c  |  2 +-
 StdLib/LibC/StdLib/realpath.c  |  2 +-
 StdLib/LibC/Stdio/vfscanf.c|  2 +-
 StdLib/LibC/Uefi/InteractiveIO/TerminalFunctions.c |  8 
 StdLib/LibC/Uefi/SysCalls.c|  8 
 StdLib/LibC/Wchar/String.c |  2 +-
 StdLib/LibC/gdtoa/gdtoaimp.h   |  2 +-
 StdLib/PosixLib/Gen/dirname.c  |  2 +-
 21 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/StdLib/BsdSocketLib/ns_addr.c b/StdLib/BsdSocketLib/ns_addr.c 
index 4360b0c..36fe379 100644
--- a/StdLib/BsdSocketLib/ns_addr.c
+++ b/StdLib/BsdSocketLib/ns_addr.c
@@ -72,9 +72,9 @@ ns_addr(
 
   /*
* First, figure out what he intends as a field separtor.
-   * Despite the way this routine is written, the prefered
+   * Despite the way this routine is written, the preferred
* form  2-272.AA001234H.01777, i.e. XDE standard.
-   * Great efforts are made to insure backward compatability.
+   * Great efforts are made to insure backward compatibility.
*/
   if ((hostname = strchr(buf, '#')) != NULL)
 separator = '#';
diff --git a/StdLib/BsdSocketLib/res_comp.c b/StdLib/BsdSocketLib/res_comp.c 
index 7c327fa..8e52e32 100644
--- a/StdLib/BsdSocketLib/res_comp.c
+++ b/StdLib/BsdSocketLib/res_comp.c
@@ -108,7 +108,7 @@ static char rcsid[] = "$Id: res_comp.c,v 1.1.1.1 2003/11/19 
01:51:35 kyu3 Exp $"
 
 /*
  * Expand compressed domain name 'comp_dn' to full domain name.
- * 'msg' is a pointer to the begining of the message,
+ * 'msg' is a pointer to the beginning of the message,
  * 'eomorig' points to the first location after the message,
  * 'exp_dn' is a pointer to a buffer of size 'length' for the result.
  * Return size of compressed name or -1 if there was an error.
diff --git a/StdLib/BsdSocketLib/res_config.h b/StdLib/BsdSocketLib/res_config.h
index 4f4afdf..e3128e1 100644
--- a/StdLib/BsdSocketLib/res_config.h
+++ b/StdLib/BsdSocketLib/res_config.h
@@ -1,6 +1,6 @@
 #define DEBUG   1   /* enable debugging code (needed for dig) */
 #define RESOLVSORT  /* allow sorting of addresses in gethostbyname */
-#define RFC1535 /* comply with RFC1535 (STRONGLY reccomended by vixie)*/
+#define RFC1535 /* comply with RFC1535 (STRONGLY recommended by vixie)*/
 #undef  USELOOPBACK /* res_init() bind to localhost */  #undef  SUNSECURITY /* 
verify gethostbyaddr() calls - WE DONT NEED IT  */  #define 
MULTI_PTRS_ARE_ALIASES 1 /* fold multiple PTR records into aliases */ diff 
--git a/StdLib/BsdSocketLib/res_init.c b/StdLib/BsdSocketLib/res_init.c index 
9df7d4f..449cb17 100644
--- a/StdLib/BsdSocketLib/res_init.c
+++ b/StdLib/BsdSocketLib/res_init.c
@@ -134,7 +134,7 @@ struct __res_state _res
  * there will have precedence.  Otherwise, the server address is set to
  * INADDR_ANY and the default domain name comes from the gethostname().
  *
- * An interrim version of this code (BIND 4.9, pre-4.4BSD) used 127.0.0.1
+ * An interim version of this code (BIND 4.9, pre-4.4BSD) used 
+ 127.0.0.1
  * rather than INADDR_ANY ("0.0.0.0") as the default name server address
  * since it was noted that INADDR_ANY actually meant ``the first interface
  * you "ifconfig"'d at boot time'' and if this was a SLIP or PPP interface, 
diff --git a/StdLib/Include/arpa/telnet.h b/StdLib/Include/arpa/telnet.h index 
d7c8ecb..04c4a30 100644
--- a/StdLib/Include/arpa/telnet.h
+++ b/StdLib/Include/arpa/telnet.h
@@ -213,7 +213,7 @@ char *telo

Re: [edk2-devel] [PATCH v3 09/39] MdePkg: Add a new library named PeiServicesTablePointerLibReg

2023-11-24 Thread Laszlo Ersek
On 11/22/23 02:47, Chao Li wrote:
> Hi Laszlo,
> 
> 
> Thanks,
> Chao
> On 2023/11/21 22:37, Laszlo Ersek wrote:
>> On 11/17/23 10:59, Chao Li wrote:
>>> Since some ARCH or platform not require execute code on memory during
>>> PEI phase, some values may transferred via CPU registers.
>>>
>>> Adding PeiServcieTablePointerLibReg to allow set and get the PEI service
>>> table pointer depend by a CPU register, this library can accommodate lot
>>> of platforms who not require execte code on memory during PEI phase.
>>>
>>> Adding PeiServiceTablePointerLibReg to allows setting and getting the
>>> PEI service table pointer via CPU registers, and the library can
>>> accommodate many platforms that do not need to execute code on memory
>>> during the PEI phase.
>>>
>>> The idea of this library is derived from
>>> ArmPkg/Library/PeiServicesTablePointerLib/
>>>
>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
>>>
>>> Cc: Michael D Kinney 
>>> Cc: Liming Gao 
>>> Cc: Zhiguang Liu 
>>> Cc: Leif Lindholm 
>>> Cc: Ard Biesheuvel 
>>> Cc: Sami Mujawar 
>>> Cc: Laszlo Ersek 
>>> Cc: Sunil V L 
>>> Signed-off-by: Chao Li 
>>> ---
>>>  .../Library/PeiServicesTablePointerLib.h  | 37 +++-
>>>  .../PeiServicesTablePointer.c | 86 +++
>>>  .../PeiServicesTablePointerLib.uni| 20 +
>>>  .../PeiServicesTablePointerLibReg.inf | 40 +
>>>  MdePkg/MdePkg.dsc |  1 +
>>>  5 files changed, 180 insertions(+), 4 deletions(-)
>>>  create mode 100644 
>>> MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointer.c
>>>  create mode 100644 
>>> MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointerLib.uni
>>>  create mode 100644 
>>> MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointerLibReg.inf
>> In my opinion, the PeiServicesTablePointerLib class header should not be
>> extended with new interfaces. I understand that the generality is
>> attractive, but it is not put to use; only the loongarch architecture
>> applies the new interfaces (in the subsequent patch), and for example
>> the ARM code (ArmPkg/Library/PeiServicesTablePointerLib) is not reworked
>> in terms of these new interfaces.
> 
> This libarary have ability of accommodate more ARCH why not? I checked
> the PI SPEC, all ARCH except IA32 and X64 using the register mechanism,
> if this library can be approved, all of them can moved into this
> libraryso that code con be reused more, I think this library is fine.

The library may be fine from a design point of view, but without
actually putting the extra generality to use, it's a waste. It's a
maintenance burden. There's a name for this anti-pattern: it is called
"speculative generality". "It might be useful down the road."

The new generality is only useful if it carries its own weight; namely,
if other platform code (aarch64, x64) is converted to it immediately, in
the same series. (I'm not asking for this series to be longer. You could
even split it up into multiple "waves" of series.) Just saying that
"could prove useful later" is a prime way to generate technical debt.

> 
>> What's more, the new library interfaces, even though they are exposed in
>> the lib class header, are not implemented for other architectures, so
>> they aren't even callable on those arches.
> The patch 10 in this series has added LoongArch instance of this
> library, please check.

Yes, I'm aware. That's not the point.

When you extend a library *class* with a new API, that means all
*clients* of the library class can stat calling that API. Which in turn
means that *all* existent instances of the library class must implement
the API as well.

Your series extends the lib class with a new API, but (IIUC) only
implements the new API in one (new) lib instance, and not in the other
(existent) instances. This has the potential to cause linkage errors,
dependent on the actual library instance that a platform DSC chooses.


>> I'm commenting on this patch and the subsequent patch in the series
>> together, as seen squashed together. NB I'm not an MdePkg maintainer, so
>> this is just my opinion.
> So, Mike and Liming, what do your think?
>> (1) As noted above, the library class should not be modified.
>>
>> (2) Modifying the *comments* in
>> "MdePkg/Include/Library/PeiServicesTablePointerLib.h" is welcome, I
>> think, but then we might want to add a (separate!) patch for removing
>> the Itanium language, as edk2 no longer supports Itanium.
>>
>> (3) The PeiServicesTablePointerLibReg instance should be called
>> PeiServicesTablePointerLibCsrKs0 or just PeiServicesTablePointerLibKs0.
> This library will be a public libray which using the reigster mechanism,
> so the name like PeiServiceTablePointerLibCsrKs0 would not appropriate.

Of course that name is wrong for a generic library instance, but my
whole point is that this library instance should be loongarch-specific.

(Unless you port the existent (x64 IDT / aarch

Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Restart dispatcher once MmEntryPoint is registered

2023-11-24 Thread Laszlo Ersek
On 11/23/23 17:20, Xu, Wei6 wrote:
> Thanks a lot for the review. Replied inline.
> 
> BR,
> Wei
> 
>> -Original Message-
>> From: Laszlo Ersek 
>> Sent: Wednesday, November 22, 2023 7:46 PM
>> To: devel@edk2.groups.io; Xu, Wei6 
>> Cc: Ard Biesheuvel ; Sami Mujawar
>> ; Ni, Ray 
>> Subject: Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Restart
>> dispatcher once MmEntryPoint is registered
>>
>> On 11/20/23 09:30, Xu, Wei6 wrote:
>>> Defer the dispatch of the remaining MM drivers once the CPU driver has
>>> been dispatched.
>>>
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4599
>>>
>>> In MmDispatcher, return immediately if the MM Entry Point was registered.
>>> Then the MM IPL will reinvoke the MM Core Dispatcher. This is required
>>> so MM Mode may be enabled as soon as all the dependent MM Drivers for
>>> MM Mode have been dispatched.
>>>
>>> Introduce a FeatureFlag PCD to control if MmDispatcher returns or not
>>> when MmEntryPointPoint is registered. Default value is FALSE.
>>>
>>> Cc: Ard Biesheuvel 
>>> Cc: Sami Mujawar 
>>> Cc: Ray Ni 
>>> Signed-off-by: Wei6 Xu 
>>> ---
>>>  StandaloneMmPkg/Core/Dispatcher.c | 76
>> +++
>>>  StandaloneMmPkg/Core/StandaloneMmCore.c   |  1 +
>>>  StandaloneMmPkg/Core/StandaloneMmCore.inf |  3 +
>>>  StandaloneMmPkg/StandaloneMmPkg.dec   |  6 ++
>>>  4 files changed, 86 insertions(+)
>>>
>>> diff --git a/StandaloneMmPkg/Core/Dispatcher.c
>>> b/StandaloneMmPkg/Core/Dispatcher.c
>>> index b1ccba15b060..a3983785070b 100644
>>> --- a/StandaloneMmPkg/Core/Dispatcher.c
>>> +++ b/StandaloneMmPkg/Core/Dispatcher.c
>>> @@ -586,6 +586,7 @@ MmDispatcher (
>>>LIST_ENTRY   *Link;
>>>EFI_MM_DRIVER_ENTRY  *DriverEntry;
>>>BOOLEAN  ReadyToRun;
>>> +  BOOLEAN  PreviousMmEntryPointRegistered;
>>>
>>>DEBUG ((DEBUG_INFO, "MmDispatcher\n"));
>>>
>>> @@ -649,6 +650,11 @@ MmDispatcher (
>>>DriverEntry->Initialized = TRUE;
>>>RemoveEntryList (&DriverEntry->ScheduledLink);
>>>
>>> +  //
>>> +  // Cache state of MmEntryPointRegistered before calling entry point
>>> +  //
>>> +  PreviousMmEntryPointRegistered =
>>> + gMmCorePrivate->MmEntryPointRegistered;
>>> +
>>>//
>>>// For each MM driver, pass NULL as ImageHandle
>>>//
>>> @@ -667,6 +673,22 @@ MmDispatcher (
>>>  DEBUG ((DEBUG_INFO, "StartImage Status - %r\n", Status));
>>>  MmFreePages (DriverEntry->ImageBuffer, DriverEntry-
>>> NumberOfPage);
>>>}
>>> +
>>> +  if (!PreviousMmEntryPointRegistered && gMmCorePrivate-
>>> MmEntryPointRegistered) {
>>> +if (FeaturePcdGet (PcdRestartMmDispatcherOnceMmEntryRegistered))
>> {
>>> +  //
>>> +  // Return immediately if the MM Entry Point was registered by the
>> MM
>>> +  // Driver that was just dispatched. The MM IPL will reinvoke the 
>>> MM
>>> +  // Core Dispatcher. This is required so MM Mode may be enabled as
>> soon
>>> +  // as all the dependent MM Drivers for MM Mode have been
>> dispatched.
>>> +  // Once the MM Entry Point has been registered, then MM Mode will
>> be
>>> +  // used.
>>> +  //
>>> +  gRequestDispatch   = TRUE;
>>> +  gDispatcherRunning = FALSE;
>>> +  return EFI_NOT_READY;
>>> +}
>>> +  }
>>>  }
>>>
>>>  //
>>> @@ -897,6 +919,60 @@ MmAddToDriverList (
>>>return EFI_SUCCESS;
>>>  }
>>>
>>> +/**
>>> +  Event notification that is fired MM IPL to dispatch the previously
>> discovered MM drivers.
>>> +
>>> +  @param[in]   DispatchHandle  The unique handle assigned to this
>> handler by MmiHandlerRegister().
>>> +  @param[in]   Context Points to an optional handler context 
>>> which
>> was specified when the
>>> +   handler was registered.
>>> +  @param[in, out]  CommBuffer  A pointer to a collection of data in
>> memory that will
>>> +   be conveyed from a non-MM environment 
>>> into an MM
>> environment.
>>> +  @param[in, out]  CommBufferSize  The size of the CommBuffer.
>>> +
>>> +  @return EFI_SUCCESS  Dispatcher is executed.
>>> +
>>> +**/
>>> +EFI_STATUS
>>> +EFIAPI
>>> +MmDriverDispatchHandler (
>>> +  IN EFI_HANDLE  DispatchHandle,
>>> +  IN CONST VOID  *Context OPTIONAL,
>>> +  IN OUT VOID*CommBuffer  OPTIONAL,
>>> +  IN OUT UINTN   *CommBufferSize  OPTIONAL
>>> +  )
>>> +{
>>> +  EFI_STATUS  Status;
>>> +
>>> +  DEBUG ((DEBUG_INFO, "MmDriverDispatchHandler\n"));
>>> +
>>> +  //
>>> +  // Execute the MM Dispatcher on MM drivers that have been
>>> + discovered  // previously but not dispatched.
>>> +  //
>>> +  Status = MmDispatcher ();
>>> +
>>> +  //
>>> +  // Check to see if CommBuffer and CommBufferSize are valid  //  if
>>> + ((CommBuffer != NULL) && (CommBufferSize != NULL)) {
>>> +if (*CommBufferSize > 0) {
>>> +  if (!EFI_ER

[edk2-devel] [edk2-libc Patch 1/1] edk2-libc/StdLib: Fixed typo issues in multiple files

2023-11-24 Thread Vishal R
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4579

This commit fixes the various typo issues found in documentation strings
in multiple files issue reported via the BZ4579
These changes are documentation updates only and does not affect the
functionality of the code

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Vishal R 
---
 StdLib/BsdSocketLib/ns_addr.c  |  4 ++--
 StdLib/BsdSocketLib/res_comp.c |  2 +-
 StdLib/BsdSocketLib/res_config.h   |  2 +-
 StdLib/BsdSocketLib/res_init.c |  2 +-
 StdLib/Include/arpa/telnet.h   |  2 +-
 StdLib/Include/errno.h |  2 +-
 StdLib/Include/locale.h|  2 +-
 StdLib/Include/net/if.h|  8 
 StdLib/Include/netns/ns.h  |  2 +-
 StdLib/Include/stdio.h |  2 +-
 StdLib/Include/stdlib.h|  6 +++---
 StdLib/Include/sys/termios.h   | 14 +++---
 StdLib/Include/sys/wait.h  |  2 +-
 StdLib/LibC/Main/Arm/flt_rounds.c  |  2 +-
 StdLib/LibC/StdLib/realpath.c  |  2 +-
 StdLib/LibC/Stdio/vfscanf.c|  2 +-
 StdLib/LibC/Uefi/InteractiveIO/TerminalFunctions.c |  8 
 StdLib/LibC/Uefi/SysCalls.c|  8 
 StdLib/LibC/Wchar/String.c |  2 +-
 StdLib/LibC/gdtoa/gdtoaimp.h   |  2 +-
 StdLib/PosixLib/Gen/dirname.c  |  2 +-
 21 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/StdLib/BsdSocketLib/ns_addr.c b/StdLib/BsdSocketLib/ns_addr.c
index 4360b0c..36fe379 100644
--- a/StdLib/BsdSocketLib/ns_addr.c
+++ b/StdLib/BsdSocketLib/ns_addr.c
@@ -72,9 +72,9 @@ ns_addr(
 
   /*
* First, figure out what he intends as a field separtor.
-   * Despite the way this routine is written, the prefered
+   * Despite the way this routine is written, the preferred
* form  2-272.AA001234H.01777, i.e. XDE standard.
-   * Great efforts are made to insure backward compatability.
+   * Great efforts are made to insure backward compatibility.
*/
   if ((hostname = strchr(buf, '#')) != NULL)
 separator = '#';
diff --git a/StdLib/BsdSocketLib/res_comp.c b/StdLib/BsdSocketLib/res_comp.c
index 7c327fa..8e52e32 100644
--- a/StdLib/BsdSocketLib/res_comp.c
+++ b/StdLib/BsdSocketLib/res_comp.c
@@ -108,7 +108,7 @@ static char rcsid[] = "$Id: res_comp.c,v 1.1.1.1 2003/11/19 
01:51:35 kyu3 Exp $"
 
 /*
  * Expand compressed domain name 'comp_dn' to full domain name.
- * 'msg' is a pointer to the begining of the message,
+ * 'msg' is a pointer to the beginning of the message,
  * 'eomorig' points to the first location after the message,
  * 'exp_dn' is a pointer to a buffer of size 'length' for the result.
  * Return size of compressed name or -1 if there was an error.
diff --git a/StdLib/BsdSocketLib/res_config.h b/StdLib/BsdSocketLib/res_config.h
index 4f4afdf..e3128e1 100644
--- a/StdLib/BsdSocketLib/res_config.h
+++ b/StdLib/BsdSocketLib/res_config.h
@@ -1,6 +1,6 @@
 #define DEBUG   1   /* enable debugging code (needed for dig) */
 #define RESOLVSORT  /* allow sorting of addresses in gethostbyname */
-#define RFC1535 /* comply with RFC1535 (STRONGLY reccomended by vixie)*/
+#define RFC1535 /* comply with RFC1535 (STRONGLY recommended by vixie)*/
 #undef  USELOOPBACK /* res_init() bind to localhost */
 #undef  SUNSECURITY /* verify gethostbyaddr() calls - WE DONT NEED IT  */
 #define MULTI_PTRS_ARE_ALIASES 1 /* fold multiple PTR records into aliases */
diff --git a/StdLib/BsdSocketLib/res_init.c b/StdLib/BsdSocketLib/res_init.c
index 9df7d4f..449cb17 100644
--- a/StdLib/BsdSocketLib/res_init.c
+++ b/StdLib/BsdSocketLib/res_init.c
@@ -134,7 +134,7 @@ struct __res_state _res
  * there will have precedence.  Otherwise, the server address is set to
  * INADDR_ANY and the default domain name comes from the gethostname().
  *
- * An interrim version of this code (BIND 4.9, pre-4.4BSD) used 127.0.0.1
+ * An interim version of this code (BIND 4.9, pre-4.4BSD) used 127.0.0.1
  * rather than INADDR_ANY ("0.0.0.0") as the default name server address
  * since it was noted that INADDR_ANY actually meant ``the first interface
  * you "ifconfig"'d at boot time'' and if this was a SLIP or PPP interface,
diff --git a/StdLib/Include/arpa/telnet.h b/StdLib/Include/arpa/telnet.h
index d7c8ecb..04c4a30 100644
--- a/StdLib/Include/arpa/telnet.h
+++ b/StdLib/Include/arpa/telnet.h
@@ -213,7 +213,7 @@ char *telopts[NTELOPTS+1] = {
 #defineNSLC30
 
 /*
- * For backwards compatability, we define SLC_NAMES to be the
+ * For backwards compatibility, we define SLC_NAMES to be the
  * list of names if SLC_NAMES is not defined.
  */
 #defineSLC_NAMELIST"0", "SYNCH", "BRK", "IP", "AO", "AYT", "E

[edk2-devel] [edk2-libc Patch 0/1] StdLib: Fixed typo issues in multiple files

2023-11-24 Thread Vishal R
This commit fixes the various typo issues found in documentation strings
in multiple files issue reported via the BZ4579
These changes are documentation updates only and does not affect the
functionality of the code

Vishal R (1):
  edk2-libc/StdLib: Fixed typo issues in multiple files

 StdLib/BsdSocketLib/ns_addr.c  |  4 ++--
 StdLib/BsdSocketLib/res_comp.c |  2 +-
 StdLib/BsdSocketLib/res_config.h   |  2 +-
 StdLib/BsdSocketLib/res_init.c |  2 +-
 StdLib/Include/arpa/telnet.h   |  2 +-
 StdLib/Include/errno.h |  2 +-
 StdLib/Include/locale.h|  2 +-
 StdLib/Include/net/if.h|  8 
 StdLib/Include/netns/ns.h  |  2 +-
 StdLib/Include/stdio.h |  2 +-
 StdLib/Include/stdlib.h|  6 +++---
 StdLib/Include/sys/termios.h   | 14 +++---
 StdLib/Include/sys/wait.h  |  2 +-
 StdLib/LibC/Main/Arm/flt_rounds.c  |  2 +-
 StdLib/LibC/StdLib/realpath.c  |  2 +-
 StdLib/LibC/Stdio/vfscanf.c|  2 +-
 StdLib/LibC/Uefi/InteractiveIO/TerminalFunctions.c |  8 
 StdLib/LibC/Uefi/SysCalls.c|  8 
 StdLib/LibC/Wchar/String.c |  2 +-
 StdLib/LibC/gdtoa/gdtoaimp.h   |  2 +-
 StdLib/PosixLib/Gen/dirname.c  |  2 +-
 21 files changed, 39 insertions(+), 39 deletions(-)

-- 
2.39.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111697): https://edk2.groups.io/g/devel/message/111697
Mute This Topic: https://groups.io/mt/102779150/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Restart dispatcher once MmEntryPoint is registered

2023-11-24 Thread Laszlo Ersek
On 11/22/23 16:11, Ard Biesheuvel wrote:
> On Wed, 22 Nov 2023 at 12:45, Laszlo Ersek  wrote:
>>
> ...
>> (3) Most importantly, speaking to a larger context, I don't understand
>> how this patch can work *at all*.
>>
>> Namely, I can find no MM IPL inside edk2!
>>
>> The DXE and MM dispatcher are supposed to work together in the following
>> way:
>>
>> (3.1) Whenever the DXE Core signals the PI-defined event group
>> EFI_EVENT_GROUP_DXE_DISPATCH_GUID, the MM IPL takes notice. (The MM IPL
>> learns that the DXE Dispatcher has completed one round of dispatching,
>> and new DXE/UEFI protocols may have become available.)
>>
>> (3.2) The MM IPL notifies the MM Core to run one round of MM dispatch.
>> This gives another chance to those MM drivers that failed to launch
>> previously due to missing DXE/UEFI protocols (which they might want to
>> consume in their entry points). The notification happens via an MMI / a
>> particular communication buffer carrying
>> EFI_EVENT_GROUP_DXE_DISPATCH_GUID in the header.
>>
>> (3.3) The MM Core runs said one round of dispatch, and then *informs*
>> the MM IPL about the result. The result can be one of three cases:
>> success, error, and "restart".
>>
>> (3.4) As long as the result is "restart" (for *whatever* reason), the MM
>> IPL doesn't complete the notification function for
>> EFI_EVENT_GROUP_DXE_DISPATCH_GUID, but jumps back to step (3.2).
>>
>> In practice, this is used for handling the situation described in the
>> commit message -- namely, if the MM Core notices that the MM Entry Point
>> was installed in the last round of MM dispatch, then it exits early back
>> to the MM IPL with status "restart". The subsequent MM Dispatch run
>> gives a chance to those MM drivers that needed access to Management Mode
>> (or perhaps MM RAM). So in effect this is an "inner" re-iteration that
>> aims at noticing the MM Entry Point, instead of new DXE/UEFI protocols.
>>
> 
> The above describes traditional MM but not standalone MM. I would have
> to refer to the PI spec for details, but the primary difference is
> that SMM drivers have no access to the DXE protocol database or boot
> services at all (hence the name 'standalone'). The standalone MM is a
> separate execution context that comes into existence magically (i.e.,
> in a way not defined by PI/UEFI) and can be invoked only via special
> traps or instructions. Notably, the SMM model where the initial
> context is unified and only separated later in the boot (at EndOfDxe?)
> does not apply here. This also means that dispatching FVs into
> standalone MM and retaining other SMM legacy is meaningless, which is
> why I removed all that code.

Right, this is what I suspected. It didn't seem like your code removal
was an incidental simplification; my understanding (or more like:
guesswork) of "Standalone" in "StandaloneMmPkg" was that there was *no*
MM "IPL" to talk back to.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111696): https://edk2.groups.io/g/devel/message/111696
Mute This Topic: https://groups.io/mt/102703852/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-