OSDev.org

I see them a lot in UEFI code:

normal C calling constructs:

<return type> <function name> (<param1 type> <param1>, <param2 type> <param2>,....<paramN type><paramN>)
{
<function body>
}

in UEFI code, I see a lot:
EFI_STATUS EFIAPI <function name> (IN OUT <param1 type><param1>)
{
<function body>
}

Here I see EFI_STATUS is a return type, but how about EFIAPI, IN and OUT keywords?
May be I have grab my C primer that is collecting dust in my shell to see anything is there.

That's easy. IN, OUT, there might be also their combination are just a convenient way to hint you of a purpose of this parameter - are they input for a function, output or both. Microsoft has a lot heavier system for this. They even call it somehow, forgot it.
Above things defined just as empty macros. For example:
#define IN

As of EFIAPI, it is a calling convention (CC) specification marker. UEFI requires all defined by the specification functions to follow the convention defined by UEFI. If your compiler supports several CC, there should be one compatible with UEFI's. And then you might bind EFIAPI specifier to the compiler's keyword for that CC. Something like this:
#if defined(___cool_n_free_as_in_beer_and_vodka_compiler_blablabla)
#define EFIAPI ___declspec(CALLING_CONVENTION_COMPATIBLE_WITH_UEFI)
#elif defined(some_else_cool_n_free_compiler)
#define EFIAPI XXX
#endif

That said, mostly EFIAPI defined as an empty macro as well.

Speaking by my own experience. So far I am working with MIPS architecture, and since UEFI doesn't have this architecture included and thus, - doesn't have any CC specification for it, I chose it by myself. I chose O32 calling convention it's good and simple, everything needed. Since it's a default CC for GCC I use, I defined EFIAPI as a plain macro.

An excerpt from my own Uefi.h file, as an example:

zaval wrote:That's easy. IN, OUT, there might be also their combination are just a convenient way to hint you of a purpose of this parameter - are they input for a function, output or both. Microsoft has a lot heavier system for this. They even call it somehow, forgot it.
Above things defined just as empty macros. For example:
#define IN

As of EFIAPI, it is a calling convention (CC) specification marker. UEFI requires all defined by the specification functions to follow the convention defined by UEFI. If your compiler supports several CC, there should be one compatible with UEFI's. And then you might bind EFIAPI specifier to the compiler's keyword for that CC. Something like this:
#if defined(___cool_n_free_as_in_beer_and_vodka_compiler_blablabla)
#define EFIAPI ___declspec(CALLING_CONVENTION_COMPATIBLE_WITH_UEFI)
#elif defined(some_else_cool_n_free_compiler)
#define EFIAPI XXX
#endif

That said, mostly EFIAPI defined as an empty macro as well.

Speaking by my own experience. So far I am working with MIPS architecture, and since UEFI doesn't have this architecture included and thus, - doesn't have any CC specification for it, I chose it by myself. I chose O32 calling convention it's good and simple, everything needed. Since it's a default CC for GCC I use, I defined EFIAPI as a plain macro.

An excerpt from my own Uefi.h file, as an example:

Code: Select all

/* ABI specification */
#define EFIAPI	/* for mips32 it's o32 */

#define NULL		((PVOID)0)
#define IN
#define OUT
#define OPTIONAL
#define CONSTANT	const
#define CONST		const

thx, looks like these are something i have never bothered to deal with, will look into it.