Re: [edk2] [UnixPkg] Contemplating a UnixThunk protocol redesign

Subject: Re: [edk2] [UnixPkg] Contemplating a UnixThunk protocol redesign

From: Jordan Justen <>

To: Andrew Fish <>

Date: 2011-04-13 16:25:22

On Wed, Apr 13, 2011 at 00:14, Andrew Fish  wrote:
> On Apr 12, 2011, at 8:18 PM, Jordan Justen wrote:
>> =A0(Although, I think OsEmuLoader is a better
>> name than Sec.)
> Maybe since I was around from the beginning SEC works OK for me. The SEC =
runs first and can pass up PPIs to the PEI core. Given SEC is always on the=
 left and first in the all power point foils seems like it is a good name f=
or the 1st code that runs.

What I'm meaning is a shift in viewpoint for the nt32/unixpkg project:
1. A new InOsEmuPkg is shared between nt32 & unixpkg.  It builds an FD.
2. The remenents of nt32/unixpkg are turned into separate nmake/make
based projects which load and call InOsEmu via a well defined
interface to the code in the FD.

As a bonus, this could obsolete the need for 'edksetup.bat --nt32' and
the ELFGCC toolchain which just don't fit very well into the edk2
build environment.

One more point regarding SEC.  It now has the
gEfiTemporaryRamSupportPpiGuid responsibility, and I think this could
be implemented easier in edk2 code inside the FD.

>> =A0Also, couldn't we define this interface to be common
>> for 32 and 64-bit?
> Not sure what you mean by that? Don't use UINTN or pointers? It is a shar=
ed protocol today. We get more deltas from ABI issues. So on IA-32 there is=
 a gasket for running on OS X as the stack alignment requirement for OS X i=
s stricter than the EFIABI. For X64 we end up with the assembly gaskets to =
change the calling convention.
> One good thing about not passing the POSIX APIs up to DXE is we can remov=
e the =A0X64/NameManglingFix.c if we are making these calls directly from S=
EC C code.

I'm meaning, that 32-bit, 64-bit, NT32, Unix, they all use the same
data structure, and thus we have common code to access them in all
cases.  Maybe they can become GUIDed HOBs, that are passed through.
But each item would indicate a service.  For example, if networking is
not available, then you wouldn't find the networking related blob.


Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!
edk2-devel mailing list