OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 5:51 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Which kernel architecture more suitable for long term driver
PostPosted: Wed Apr 03, 2019 11:17 pm 
Offline

Joined: Thu Mar 21, 2019 9:55 pm
Posts: 8
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.


Top
 Profile  
 
 Post subject: Re: Which kernel architecture more suitable for long term dr
PostPosted: Wed Apr 03, 2019 11:38 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
farcas82 wrote:
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).


Top
 Profile  
 
 Post subject: Re: Which kernel architecture more suitable for long term dr
PostPosted: Thu Apr 04, 2019 4:30 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
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


Top
 Profile  
 
 Post subject: Re: Which kernel architecture more suitable for long term dr
PostPosted: Thu Apr 04, 2019 10:22 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
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.

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Amazonbot [bot] and 18 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group