OSDev.org

What is the best way to implement hardware support in a managed code OS? Should I put it in the virtual machine or implement an API for the kernel (which is ran on the VM) for accessing ports, physical memory, etc?

I think both would work, so it's really up to you.

Putting the code in the VM would probably perform better, but exposing memory and I/O to your managed code would allow you to write everything in one language, which may be worth considering.

Personally, I'm planning on mixing managed and native code side-by-side, in an attempt to get the best of both worlds. We'll see if it works out our not.

Roman wrote:What is the best way ...

First it is required to define some criteria to assess the ways you can chose from. Next it is required to apply the criteria to all ways you have. And finally it is required to select the way with the best score. This is a general approach.

But if you wish to shorten path then you can follow ways of other people, who already defined some criteria and have selected some way to go along. But is it a really best way? Until you know the criteria you can not tell.

Roman wrote:to implement hardware support in a managed code OS?

I just use drivers. You can use them too. And is the code managed or not is irrelevant.

Roman wrote:Should I put it in the virtual machine or implement an API for the kernel

I'm working on a x86 emulator atm and the design I'm using is to put the device drivers at the VM level as this provides the fastest access. You can then expose an I/O read and write API to the kernel to allow enhancing or work arounds for an installed the device driver.

b.zaar wrote:

Roman wrote:Should I put it in the virtual machine or implement an API for the kernel

I'm working on a x86 emulator atm and the design I'm using is to put the device drivers at the VM level as this provides the fastest access. You can then expose an I/O read and write API to the kernel to allow enhancing or work arounds for an installed the device driver.

I think, this can be a security hole, can't it be? What about hardware support extension?

Roman wrote:I think, this can be a security hole, can't it be? What about hardware support extension?

The I/O api wouldn't need to be exposed to every process. Do you support any trusted software vs user software layers?

I'm not sure how you would safely expose the api from your original idea without the same kind of security hole.

b.zaar wrote:

Roman wrote:I think, this can be a security hole, can't it be? What about hardware support extension?

The I/O api wouldn't need to be exposed to every process. Do you support any trusted software vs user software layers?

I'm not sure how you would safely expose the api from your original idea without the same kind of security hole.

Managed code couldn't access memory, which belongs to VM and other managed code. It also shouldn't be able to access IO ports/memory-mapped hardware, accessed by other drivers.

For example, if there's a valid ATA driver, which operates the ATA hardware, other programs won't be able to access the ATA hardware.

So when driver code is managed, it is not a security hole, but it becomes able to cause performance problems. Maybe I could answer this question me myself, but I wanted to hear other people's opinions.