Hi,
I agree with alexfru. This is a much more complex issue than just the ABI.
farcas82 wrote:
Would a microkernel allow multiple driver APIs to work simultaneously?
In theory yes. Since a microkernel separates drivers from the kernel and communicates with them via messages. This build-up is flexible enough to support several message types and with that several APIs. For example you could accept Minix like messages to incorporate Minix drivers and you could write a Linux driver task in which you would be able to load Linux kernel modules; similarly you could have an UDI task or UDI driver wrapper tasks etc. But note all of these drivers expects a different device representation, with different set of functions, which makes this approach extremely complex (but not impossible).
Even if you do this, the effectiveness and the usability is quite questionable. For example for a Linux driver you'd have to mirror significant portions of the Linux kernel in your task just to fullfil the symbol bindings, and we haven't spoken about runtime support. Also note that Linux kernel API is constantly changing.
I would say you better off with source compatibilty (in which your kernel provides functions, macros and structures that those foreign drivers require). For example a Linux driver calls "register_irq", which is defined in the Linux kernel as a funcion, but could be a macro to send a message in yours. Similarly you could hide the device representation behind a macro, etc. etc. etc. Still quite a big project.
There has been several attempts to start a common driver base for hobby OSes, but all of them failed. The closest to succeed I think was
Common Driver Interface. The other alternative,
Uniform Driver Interface was created (to my humble opinion) much more to frighten out Open Source developers than to help them. But be my guest, read the doc.
Cheers,
bzt