https://bugzilla.tianocore.org/show_bug.cgi?id=1734
Remove the following packages and move them to the new
edk2-libc repository
* AppPkg
* StdLib
* StdLibPrivateInternalFiles
Cc: Jaben Carsey
Cc: Daryl McDaniel
Signed-off-by: Michael D Kinney
---
AppPkg
Maintainers.txt
Cc: Andrew Fish
Cc: Laszlo Ersek
Cc: Leif Lindholm
Signed-off-by: Michael D Kinney
---
README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README b/README
index b640a482f9..60f14a654a 100644
--- a/README
+++ b/README
@@ -27,7 +27,7 @@ Process for creating, using, and
When building OpenSSL, the OpenBSD/FreeBSD/DFBSD code in crypto/uid.c
calls issetugid(). Add the declaration of this function to
CrtLibSupport.h to avoid the need to patch the openssl code on these
platforms.
Signed-off-by: Rebecca Cran
---
CryptoPkg/Library/Include/CrtLibSupport.h | 1 +
1
Ard,
Saw your patch to cache the GUID table. The ESRT Table
is not that much bigger, so the algorithm may be simpler
if you just make a copy of the ESRT table with the
active entries.
* 16+24 bytes per ESRT entry.
* 16 bytes/entry for just the GUID.
The only advantage of checking against the
The DxeCapsuleLibFmp code accesses the ESRT table to decide whether
a certain capsule is an FMP capsule. Since the UEFI spec mandates
that the ESRT resides in EfiBootServicesData memory, this results
in problems at OS runtime, since the firmware implementation itself
cannot access memory that has
On Fri, 19 Apr 2019 at 20:38, Ard Biesheuvel wrote:
>
> On Fri, 19 Apr 2019 at 20:23, Kinney, Michael D
> wrote:
> >
> > Ard,
> >
> > Let's see if we can remove the ESRT access from those
> > paths. That would be the better fix.
> >
>
> I am not that familiar with this code, but it seems that
On Fri, 19 Apr 2019 at 20:23, Kinney, Michael D
wrote:
>
> Ard,
>
> Let's see if we can remove the ESRT access from those
> paths. That would be the better fix.
>
I am not that familiar with this code, but it seems that the only
reason we access the ESRT at runtime is to check whether a capsule
On Fri, 19 Apr 2019 at 20:08, Kinney, Michael D
wrote:
>
> Ard,
>
> Where is the use of ESRT at runtime?
>
DxeCapsuleLibFmp is invoked at runtime by the UpdateCapsule() and
QueryCapsuleCapabilities() code.
The Canonical FWTS crashes on this runtime service on some ARM and x86
systems due to
Ard,
Where is the use of ESRT at runtime?
The SetVa conversion of the ESRT table may be an old artifact
that we should consider removing.
Thanks,
Mike
> -Original Message-
> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of Ard
> Biesheuvel
> Sent: Friday, April
On Fri, 19 Apr 2019 at 19:36, Michael D Kinney
wrote:
>
> Hi Ard,
>
> The UEFI Specification Section 23.3 says:
>
> "The ESRT shall be stored in memory of type EfiBootServicesData."
>
> If an RT driver needs ESRT info after ExitBootServices(), then the
> RT driver should collect that
Hi Ard,
The UEFI Specification Section 23.3 says:
"The ESRT shall be stored in memory of type EfiBootServicesData."
If an RT driver needs ESRT info after ExitBootServices(), then the
RT driver should collect that information before ExitBootServices().
Best regards,
Mike
>
Given that the firmware itself may access the ESRT table when the OS
invokes the UpdateCapsule () boot service, it requires a virtual mapping
and so it needs to be allocated from RtServicesData memory.
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Universal/EsrtDxe/EsrtDxe.c | 3 ++-
1 file
Hi Laszlo,
1. If we could put some human resources into stable-branch(LTS), so could you
give us an rough assessment, how many people should we put them into that? :)
2. If we make a stable-branch(LTS) into reality, we can invent some rules,
likes one year(or two years) to release a LTS
13 matches
Mail list logo
