Generic Kernel API

[Chuck Swiger]

Scott Long wrote:
> Julian Elischer wrote:
[ ... ]
>> but if we could implement it we could run apple drivers....
>> (when they move to x86)
> 
> No, we can't, unless we emulate the rest of the kernel API in OSX.
> IOKit doesn't describe the entire kernel API.  Think of it as 'newbus
> done right' and nothing more.  The rest of the kernel interfaces are
> up for grabs.  Some look and act like their BSD counterparts, some do
> not.

Scott's right that the IOKit is not a complete set of calls.

The primary thing [1] that would be missing for Apple's drivers would be Mach 
messaging and Mach memory calls, which provide some of the underlying 
serialization capabilites of events, or clearly pertain to DMA (respectively).

Apple has a portability layer written for Solaris, HP/UX, and even Windows 
which has a nmserver daemon which handles Mach messaging, and a shim for Mach 
memory calls using the SysV shared-memory interface.  This has been included 
with PDO/EOF, WebObjects, and the FoundationKit packages with slight name 
variantions over time.

The code is probably used by the ports of lookupd and netinfod...?

-- 
-Chuck

[1]: The complete KPI list for compliant drivers ought to be:

com.apple.kernel.iokit, com.apple.kernel.libkern

...which would be enough for open source drivers, but a complete emulation 
layer would probably involve much of:

com.apple.kernel, com.apple.kernel.mach, com.apple.kernel.bsd, 
com.apple.kernel.libkern, com.apple.kernel.iokit

Fortunately, the upstream BSD layer is reasonably close to what FreeBSD has, 
except for Mach exception handling versus traditional BSD signals.

MachO is not that different from ELF, and GCC already supports the BFD for it.
There is some difference in dynamic linking semantics and namespaces, and 
someone would have to figure out the C++ name mangling, too.

If this part was done, you might obtain reasonable compatibility with closed 
drivers available as binaries only, similar to what Project Evil/NDIS does now.