I/O in a Hardware Abstraction Layer

[Marionumber1]

Right now, I'm starting to work on a Hardware Abstraction Layer for my OS, because I want it to be a very portable system. It's designed to be like the Windows NT HAL, where the entire kernel runs on top of it. So far, I've decided that these things need to be in the HAL:

-I/O (Port I/O vs. MMIO)
-Interrupts (Exceptions and IRQs)
-Timers (PIT, APIC Timer, HPET)
-Virtual Memory
-CPU Specific Parts of Multitasking (Context Switching)

Most of the functions are pretty straightforward, but I'm still wondering about I/O. Since x86 is basically the only architecture that uses Port I/O (and even that's getting phased out), I definitely need to abstract the I/O interface somehow. But how exactly would I do that when Port I/O and MMIO are so different? My current idea is modifying the I/O functions to take the memory base address as another argument. On x86, if it's 0, a normal port operation is performed, but otherwise, there's a MMIO read or write performed. On any other architecture, it's used to do only MMIO reads and writes. Like so:

Code: Select all

unsigned char inportb(unsigned int base, unsigned short port);
void outportb(unsigned int base, unsigned short port, unsigned char data);

But that still feels kind of weird, and isn't a very good abstraction in my opinion. I want to know how people would implement an abstraction of the I/O interface.

[gerryg400]

Right now, I'm starting to work on a Hardware Abstraction Layer for my OS, ...

It sounds like you are planning to design from the bottom up.

To improve portability, perhaps a better idea is to design your kernel from the top down. Specify the kernel in terms of its functional blocks and how those blocks will meet your requirements. Then design each of those blocks. Forget about hardware. Once you've done that you'll probably find that you don't need a HAL at all but just a few motherboard or chip drivers to sit underneath your kernel. Sometimes it's better to keep things simple to make them portable.

With regard to I/O I don't think any abstraction is required. inport, outport and friends are abstracted well enough. The interface is known to all low-level software engineers and the functions themselves represent our understanding of how 'ports' work from a software point of view. By hiding that you are obfuscating what is a very simple concept.

[Mikemk]

You forgot the most important part: A custom bytecode, and an interpreter so the kernel runs across processors

[zeitue]

You forgot the most important part: A custom bytecode, and an interpreter so the kernel runs across processors

That would be awesome, but would it be slow?

[xenos]

You forgot the most important part: A custom bytecode, and an interpreter so the kernel runs across processors

I guess he wants the source to be portable, not the kernel binary.

Programming is 80% Math, 20% Grammer, and 10% Creativity

That leaves -10% for spelling.

[Mikemk]

Programming is 80% Math, 20% Grammer, and 10% Creativity

That leaves -10% for spelling.

lol

|
|
\/

[Nessphoro]

Quote:
Programming is 80% Math, 20% Grammer, and 10% Creativity

That leaves -10% for spelling.

Damn, I always though it was supposed to be a sort of ironic joke. (Regarding his signature, at least)

[Mikemk]

Quote:
Programming is 80% Math, 20% Grammer, and 10% Creativity

That leaves -10% for spelling.

Damn, I always though it was supposed to be a sort of ironic joke. (Regarding his signature, at least)

It is.

[zeitue]

This might be what you're wanting?
This is how Amiga OS4 does it's HAL as a micro kernel then the actual kernel is implemented as libraries.

[Marionumber1]

I've decided to do something similar to the Windows NT HAL. It has functions for doing both Port I/O and MMIO. On i386, the Port I/O functions will do port instructions, while on other platforms, they do MMIO. The MMIO instructions do MMIO on all platforms.

Is this a reccommended design? I'm not sure if Port I/O or MMIO belongs in the HAL, but I don't know where else they would go. I think this would benefit things such as an EHCI driver, where it can get a MMIO base address and use HAL I/O functions to write it, but only if MMIO also has differences in implementation between platforms. I've read that CPU caching affects buffered MMIO on i386, but I don't know whether there are any similar differences on other platforms.