Which kernel architecture more suitable for long term driver

[farcas82]

Which kernel architecture is more suitable for long term binary kernel interfaces. Would a microkernel allow multiple driver APIs to work simultaneously? Basically I want to allow compatible binary drivers in my OS as the OS evolves so that past effort is not wasted.

[alexfru]

Which kernel architecture is more suitable for long term binary kernel interfaces. Would a microkernel allow multiple driver APIs to work simultaneously? Basically I want to allow compatible binary drivers in my OS as the OS evolves so that past effort is not wasted.

I think the problem is bigger than binary interfaces. As you change logic/behavior, you break compatibility beyond just the interface. And you probably can't foresee everything (or we would have Windows and Linux drivers widely compatible with different OS versions).

[bzt]

Hi,

I agree with alexfru. This is a much more complex issue than just the ABI.

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

[Korona]

I agree with the previous posters. I think the situation is even work: Your own code will evolve, too. You will want to deprecate your own interfaces sometimes. For a microkernel, this does not only apply to the kernel itself but also to the protocols that your drivers use to communicate with each other.

A quick grep in my own code: managarm (which is microkernel based) is about 4 years old and has 56 syscalls, but the highest allocated number is 99, so I refactored or removed 43 of them. Clearly, this rate of change is constantly decreasing. However, regardless of how much time you spend on design, it will never be possible to get everything right on the first try.