Mill Computing, Inc. › Forums › The Mill › Architecture › Peripherals
- AuthorPosts
- #3055 |
Hi Ivan,
I have heard you say multiple times that the mill has no privileged instructions. That restricting access is done via turfs.
How would a driver react to things like hardware interrupts?
Does the driver pass a portal address to peripherals?
How would the driver send data to peripherals? do you map some memory addresses to peripherals? There’s no single answer here because there are tons of peripherals with idiosyncratic access mechanisms. The simplest peripherals are accessed by MMIO and normal Mill memory protection controls the access. More complex “smart” peripherals may be partly MMIO and partly handshake protocols using interrupts. Interrupts are fielded by the hardware and dispatched through a fairly conventional vector and appear to the handler to have been a normal function call with belt arguments supplied by the hardware unique to the particular interrupt. Normally the vector entry will be a portal rather than a function pointer, so the handler runs in its own protection domain rather than that of the interrupted program.
Once a service gets its handler installed in the vector and gets permissions to access the relevant MMIO then that service “owns” the peripheral. The Device Manager service that provides access to the vector and the MMIO must be trusted code, but the particular device service need not be. That is, drivers (device services) run at application level and cannot stomp on the system.
More complex still are shared devices such as the network stack, in which there can be several levels of dispatch, but the basic organization remains the same.
- AuthorPosts
You must be logged in to reply to this topic.