Ramon van Handel wrote:
>
> >> > That would be great. Whenever you want, we can begin by
> >> > making some simple IO interface that will allow you to
> >> > efficiently move data to/from the VM/driver.
> >
> >
> >OK, what device would be a good choice for a first driver -
> >maybe a hard drive? I'd imagine this would be the simplest
> >one to do, since it can use simple read()/write() on the
> >host side.
>
> Try the keyboard. Easier. And you could make a simple serial driver (not
> a real UART compatible, just to test) --- so when you do outb(0xff, 'a')
> then
> its prints 'a' on the screen, stuff like that. Then you can write some simple
> demo programs that show off the system :)
>
> I should really be coding again, but finding the time isn't easy... :(
I could actually (conditionally) code the BIOS disk drive read/write
routine to test this interface, very simply. This way I could
nail down the non-driver side without even needing a driver.
Same for keyboard as well.
Whichever works for you.
> Good system. I'd like to expand this to other events (physical memory,
> interrupts).
Interesting. Could you elaborate a little. If I can get an idea
where you want to go with this, maybe can make some better choices
regarding initial implementation. Wouldn't want to rewrite all
20 lines of callback redirect code. :^)
Damn, almost 4am again. I must virtualize myself and run a
few copies.
#define MAX_KEVINS 256
class kevin;
vkevin = new kevin[MAX_KEVINS];
for (unsigned i=0; i<MAX_KEVINS]; i++) {
vkevin[i].hack();
}
much better...
-Kevin
