Linked by Hadrien Grasland on Fri 30th Dec 2011 08:24 UTC
Hardware, Embedded Systems In the world of alternative OS development, portability across multiple architectures is a challenging goal. Sometimes, it may be intrinsically hard to come up with hardware abstractions that work well everywhere, but many times the core problem is one of missing information. Here, I aim at learning more about the way non-x86 architectures deal with CPU IO ports, and in particular how they prevent user-mode software from accessing them.
Permalink for comment 501757
To read all comments associated with this story, please click here.
RE[2]: IO on other platforms
by bartgrantham on Sat 31st Dec 2011 03:32 UTC in reply to "RE: IO on other platforms"
bartgrantham
Member since:
2011-12-31

In a managed language, this wouldn't be a problem, but it is with C/C++ which is what drivers are written in. It's one of the reasons I've been advocating using managed code in the OS for some time.


I've heard this opinion expressed before, but I'm not sure I understand why anyone would feel this way.

What's the effective difference between a VM running in kernel space and a microkernel? Either you're trapping dangerous/unauthorized instructions in hardware or you're doing it in software. I don't really see much advantage to doing it in software except that bugs in that access layer can be updated when they are discovered.

Unless you're advocating something like what Open Firmware had where you could have drivers in bytecode that are cross-architecture compatible, but there's a performance reason why that was only used for bootstrapping and the OS shipped with CPU-specific drivers.

Reply Parent Score: 1