thanks, but for my vm, i chose my own architecture:
cpu, ram and the hub are all connected to the system bus. all external hardware is connected the the hub using "slots". all "compatible devices" must adhere some standard which i have not defined yet, but is something like this:
* must support memory-mapping
* must interface with the hub
* may support dma through the hub
the hub is like a generic hardware controller with which the cpu interfaces. it can be used to assign interrupt-codes to different devices, tell them where they are mapped in the system memory, turn them on/off, probing, signaling, etc.
another thing i dont understand why they never implemnted is a flash-bios. instead of the bios having to probe for hardware and load the os, the bios simply blits the flash to the ram and starts running. the flash will be big enough (~1mb) to contain a bootloader on it that will probe hardware, find the hdd, mount a minimal file system, and load the os. what ia-64 now did with the EFI is close to that, but still overwhelmingly complicated. the EFI is basically a minimal os with drivers and all, that you can even boot to a shell. it then uses a FAT-like file system to start the OS... but the process is too complicated.
anyway, loose, or anyone else - i have the ia64-linux-kernel book. it's quite good, but lacks on I/O. i understand the process of memory mapping is something like this:
1) find the device
2) tell it where it is mapped to and what its buffer size is
3) read/write to/from this buffer directly
let's take the screen for instance - it is mapped by default at 0xb8000 and everything you write there is displayed. but there must be some sync'ing mechanism... the textmode screen update rate is 60hz, if i write faster than that rate, and assuming the buffer is finite, the data is lost.
or if i write to a printer, but write faster than it can read, i might skip lines, etc.
using i/o ports it was simple - write and wait for acknowledgement. how is this done with memory mapping?
for my architecture, i was thinking about something like that:
each device has an internal buffer and a memory-mapped buffer. you can write to the memory-mapped one directly, and when you have finished, you signal the device through the hub. if the device is ready, it will copy the memory-mapped buffer to its internal one, acknowledge the hub, and process the data. if the device is not ready, it will not acknowledge the hub until it is, and you should wait for ack' before overwriting the memory-mapped buffer. when the device is ack' the hub will fire an interrupt.
for example, assuming our videocard is at hub-slot 1, assigned irq 9, and is mapped at 0xb8000 with a 80x25x2 buffer.
Code:
writeSomething PROC
; assign interrupt-handler to irq 9. the IVT starts at
; physical address 0, with 256 entries, each 8 bytes wide.
MOV 0+8*9, L_ack
; we some white text to the screen memory-mapped buffer
MOV 0xb8000+0, 'A'
MOV 0xb8000+1, 7
MOV 0xb8000+2, 'B'
MOV 0xb8000+3, 7
MOV 0xb8000+4, 'C'
MOV 0xb8000+5, 7
; signal the device at hub-slot 1 that we updated the buffer
SIG 1
; busy-wait
L_empty_loop:
JMP L_empty_loop
; when the hub will fire irq 9, the assigned handler will jump here
L_ack:
RET
for ack'ment, perhaps i should just use some status-register to determine if a device ack'ed, and use interrupt only when the hardware has some input... but then i couldnt tell how many times i was ack'ed before i actually handled it.
of course only the OS should interface with the hub and hardware, so user tasks dont need to mess with it. in kernel land, i could simply jump somewhere else instead of busy-waiting and do something else, and use an all-purpose interrupts handler that will know where to return to, in the event of an interrupt. it's complicated, so perhaps for the beginning at least, the kernel should just busy-wait.
any help/ideas are welcome.
[Flexibal>