Feasibility of targetting a virtual machine monitor instead

[igilham]

Hi all,

I'm new here. I've long been interested in OS design, but this is pretty much my first adventure in building stuff myself. I have taken an interest in the D language after several bad experiences of C at university, and having seen what a complex mess C++ is, I would prefer to avoid it.

I have run through the barebones examples in the Wiki and arrived at a simple design that can load a function declared as extern(C). At present the function doesn't do anything interesting, and I haven't yet had time to try and figure out how to get into real D code. I'll come to that another day.

For now, I like to ask about the feasibility of targeting a hypervisor like xen with the aim of avoiding some of the more arcane steps to getting the system up and running. Specifically, if you have a monitor already running, do you still need to deal with assembly to boot into code written in a higher level language? I've scanned the documentation, but couldn't see anything addressing this issue.

My reasoning is that decoupling the OS from the hardware should allow the whole thing to be written in the implementation language and a few API calls down to the monitor, effectively acting as a hardware abstraction layer below the OS structures.

Can this be done with current technology, is there some reason why it might not be possible, or do I just have a crazy pipe-dream?

[Kevin]

Well, yes, you can write an OS running on Xen. Don't expect it to make your life easier, though. You still need to know how the hardware works, you just can't access it directly but use Xen hypercalls instead. You will still need assembly, even though not fot booting. And as an extra bonus, you have only a short description of the hypercalls and Linux code, otherwise you're on your own.

If it's really just about avoiding the bootloader, have you had a look at Multiboot/GRUB? It's entirely possible to get a pure C (and probably also D) kernel running with it (you'll need assembly in other places, of course - same as with Xen).

[igilham]

Well, there will always be interrupt stuff requiring assembly etc. I guess I was just looking for a way to use modern software techniques on a relatively raw platform.

It sounds like the state of the art (or at least the thing people actually use) hasn't changed in any significant way since the 8088 from the perspective of getting something to run. A pity really, but once you're into higher level code most of these concerns disappear anyway, I'm sure.

I guess we're all stuck with the ugliness of x86 for the foreseeable future. I have a lot of reading to do if I intend to master the beast...

[Kevin]

Not sure what you mean by getting something to run. If you mean the state after the BIOS has finished and jumps to the bootloader - yes, nothing has changed. It's called compatibility. But nobody forces you to start at this point when you just want to write an OS (in contrary to a boot loader). Take some existing boot loader like GRUB and start off in Protected Mode with a high level language. The world looks very different from a 8088 then.

[kop99]

Hi, igilham.
Anyway, You have to know about the knowledge of architecture and asm for OS development.

[igilham]

Perhaps the logical upgrade path is to put the boot loader in the firmware on more modern machines. That still can't sidestep much of anything but it would at least make the hello world OS essentially the same as the hello world desktop application, albeit without a library call. I'll ignore the discussion on the state of EFI/UEFI for now as it is clear that it is not ready for the mainstream yet (or the mainstream isn't ready for it, either way).

As I said - lot of reading to do. That's fine though; learning stuff is my fist love.

If the 'where it's at' hasn't changed much in the last few decades, at least we have reasonably good compilers now. I look forward to delving into some of the specifics in the coming weeks/months/years.

Thanks for the input.