OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 9:20 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Newcomer's microkernel doubts
PostPosted: Wed Jul 25, 2018 2:59 pm 
Offline
Member
Member

Joined: Wed Jul 25, 2018 2:47 pm
Posts: 38
Location: Pizzaland, Southern Europe
Hi everyone, sorry for the possibly stupid questions, but I have some doubts about implementing a microkernel architecture in a x86 system that I can't seem to solve...

It basically boils down to: how do I implement device drivers?
I ideally want to make my microkernel only manage memory, scheduling and message passing, but then how do usermode device drivers communicate with the devices?

Let's take the example of an Ethernet card driver: it will obviously need to communicate with the PCI bus. But raw hardware access is not permitted to ring-3 processes,
so the communication must somehow still pass through the kernel, which presumably exposes some kind of system-call for communicating with the bus...

Doesn't this mean I would theoretically have an interface for every possible means of device interconnection (USB, serial, parallel, SMBus, whathaveyou...), thus
negating the principle of having a microkernel?

Thanks


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Wed Jul 25, 2018 3:07 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Have you thought of letting the kernel grant the appropriate hardware access rights to a device driver?


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Wed Jul 25, 2018 3:11 pm 
Offline
Member
Member

Joined: Wed Jul 25, 2018 2:47 pm
Posts: 38
Location: Pizzaland, Southern Europe
How so? No matter what the kernel does, it cannot let a usermode process manage interrupts or use
Code:
in / out
opcodes... Also, how would it manage keeping the access exclusive to only one process, how can the kernel distinguish devices?


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Wed Jul 25, 2018 5:21 pm 
Offline
Member
Member

Joined: Mon Jul 05, 2010 4:15 pm
Posts: 595
frabert wrote:
How so? No matter what the kernel does, it cannot let a usermode process manage interrupts or use
Code:
in / out
opcodes... Also, how would it manage keeping the access exclusive to only one process, how can the kernel distinguish devices?


Doesn't the x86 have a port bitmask that can be set for each user process?

Also, most microkernels indeed only processes the actual interrupts inside the kernel, but this is delegated to user processes using a callback or some kind of message system. The possibilities are many here, and you should have fun investigating them.

There are many microkernels out there, even with source. Check out how they solved it. We have L4, Genode, Mach, QNX, Zircon etc.


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Wed Jul 25, 2018 6:05 pm 
Offline
Member
Member

Joined: Tue Apr 03, 2018 2:44 pm
Posts: 36
OSwhatever wrote:
Doesn't the x86 have a port bitmask that can be set for each user process?


Yes it's the IO port bitmap in the TSS. You can grant a user process access to a port by clearing the specific bit for that port in the bitmap. And yes frabert you can actually use in/out, AFAIK the instructions themselves aren't priviledged, but its the port access.

_________________
Image is my operating system.

"...not because [it is] easy, but because [it is] hard; because that goal will serve to organize and measure the best of [my] energies and skills..."


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 12:30 am 
Offline
Member
Member

Joined: Wed Jul 25, 2018 2:47 pm
Posts: 38
Location: Pizzaland, Southern Europe
pat wrote:
Yes it's the IO port bitmap in the TSS.

Interesting, so I would actually have to use hardware-based processes, right? I can't get away with one or two TSSs and a software list of processes...


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 12:34 am 
Offline
Member
Member

Joined: Wed Oct 26, 2011 12:00 pm
Posts: 202
My operating system is a hybrid microkernel, and my device drivers run in user-mode. As have already been mentioned in this thread each TSS has an IoMap that actually is a bitmask for the ports on the system. You can set/clear each of these bits to disable or enable the access to each individual port address so the driver can use in/out instructions. In my system each memory-space has each their own io-map that I update each time the scheduler activates a new thread, this way the io-map can be per-process instead of per-TSS. For memory access to physical memory it's of course much easier to simply just map that physical memory range into the user-processes memory on request.

I use the concept of io-spaces that can be acquired by drivers and released. These io-spaces are defined by my device-manager as it enumerates the bus, and then a device-descriptor is sent to each driver as they get loaded in by the device-manager.

_________________
mollenos | gracht (protocol library) | vioarr (window-manager) | bake (package manager)


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 6:31 am 
Offline
Member
Member

Joined: Wed Jul 25, 2018 2:47 pm
Posts: 38
Location: Pizzaland, Southern Europe
MollenOS wrote:
In my system each memory-space has each their own io-map that I update each time the scheduler activates a new thread, this way the io-map can be per-process instead of per-TSS.


Ahhh that's very clever, I hadn't thought of that! Well, thanks everyone guys, I'll come back when I'll actually have something resembling multitasking working :)


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 7:17 am 
Offline
Member
Member

Joined: Tue Apr 03, 2018 2:44 pm
Posts: 36
frabert wrote:
pat wrote:
Yes it's the IO port bitmap in the TSS.

Interesting, so I would actually have to use hardware-based processes, right? I can't get away with one or two TSSs and a software list of processes...


Actually no. The majority of the TSS is useless for software context switching, however fortunately the IOPB is still used. What I do is have a fixed number of known TSS addresses, one for each CPU. I allocate a single page for each process that stores the TSS struct in the first ~100 bytes and the remaining ~4K being the bitmap, and then when they get run by that CPU's scheduler, I map that process's TSS page to that CPU's TSS address. Very similar to what Mollen does it sounds like.

_________________
Image is my operating system.

"...not because [it is] easy, but because [it is] hard; because that goal will serve to organize and measure the best of [my] energies and skills..."


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 8:11 am 
Offline
Member
Member

Joined: Wed Jul 25, 2018 2:47 pm
Posts: 38
Location: Pizzaland, Southern Europe
I'm reading the Intel manuals right now to understand what goes into the IOPB field, seems like there's not a specific length for the bit field...


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 8:35 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
It would be hopelessly inefficient if you needed a bitmap that covered the whole I/O address range. Hence you have a base and then just need to specify the ports above that. For your average device driver the ports used will fall in a fairly limited range, so the bitmap doesn't occupy a huge amount of space.

Or you could always compromise and have the device drivers as separate loadable processes running at supervisor level.


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 11:34 am 
Offline
Member
Member

Joined: Wed Jul 25, 2018 2:47 pm
Posts: 38
Location: Pizzaland, Southern Europe
iansjack wrote:
For your average device driver the ports used will fall in a fairly limited range

Makes sense, the only issue I can see is if a certain process were to use two very distant addresses... I haven't really looked into specific devices, so I'm not sure if this would be an exceptional event or a common occurrence, though.

iansjack wrote:
Or you could always compromise and have the device drivers as separate loadable processes running at supervisor level.

AND HAVE MY SUPER-SECURE OS I HAVE WRITTEN AS A HOBBY PROJECT IN MY SUMMER VACATION COMPROMISED? NEVER!!!

Jk, but I'm here for the ride as they say, I already understand how a monolithic OS manages this kind of issues, so there would not be much fun in doing that... If I wanted the easy way I could have stayed in real mode and let the BIOS do the heavy lifting for me :)


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 1:47 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Running a device driver in supervisor mode doesn't necessarily compromise your super secure OS. It works for many commercial OSs, which I would venture to suggest are probably more secure than you are ever likely to achieve. After all, your kernel still controls which drivers it is allowed to load - you can use some form of signing to prevent drivers that you haven't written from running. It's true that a badly written driver could compromise the system; but so could a badly written kernel. ;)

But it's entirely up to you as to which compromises are the most sensible and whether you are aiming for elegance or usability. Also, bear in mind that most modern devices can use memory-mapped i/o rather than i/o ports, so that may be a slight red herring. Most kernel are not strictly monolithic ormicro; there are a host of shades inbetween. And if you think either way is "easy" you are in for a few surprises along the way. If you want any sort of serious OS you can't let the BIOS do the heavy lifting. That statement implies that perhaps you understand less of the issues than you think you do.


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 2:35 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
@iansjack: Perhaps I am wrong, but I think you missed the OP's point. This isn't meant as a serious project; it is climbing a mountain because it is there. Frabert said they'd already made one OS as a monolithic kernel, and that this one was just them trying out a different approach. Frabert is doing it this way because it isn't easy, and they want to learn from it.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Newcomer's microkernel doubts
PostPosted: Thu Jul 26, 2018 2:46 pm 
Offline
Member
Member

Joined: Wed Jul 25, 2018 2:47 pm
Posts: 38
Location: Pizzaland, Southern Europe
Yeah I'm sorry it didn't come through the right way, the remark was meant as a completely non-serious observation :D Of course, I'm not saying that letting the BIOS do the heavy work in a modern OS is easy, I'm just saying that if I wanted the easy way to manage an HDD I could just do some int 13h or something and call it a day... I have no need to write a secure OS, and my comment was especially a... sideswipe? to those who think that putting everything into userland makes your OS secure.

I apologize if I sounded rude, it was not my intention.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: SemrushBot [Bot] and 23 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