3 ms·
> On a microkernel you'd just be writing any other user process, with access to a couple of ports and and maybe a special hook to handle hw interrupts This is
by zozbot123 8y ago
> On a microkernel you'd just be writing any other user process, with access to a couple of ports and and maybe a special hook to handle hw interrupts
This is a fiction. Hint: if a "user process" can wreak havoc on the system simply by misbehaving (in a way that may or may not be malicious), as drivers interacting with low-level hardware can, it's not a user process in practice, and should not be understood as one. The whole point of making that kernel vs. user space distinction in the first place is so that user programs can't wreak havoc on the system. There are plenty of things that can and should be done in userland (and oftentimes they are, see e.g. Plan9), but drivers are not among these unless you can always rely on something like IOMMU to make sure that the hardware cannot be made to misbehave in a way that affects security guarantees.
- jacquesm 8y ago> This is a fiction. No, it has existed roughly since the mid 80's. Source: programmed a whole bunch of stuff including very fast serial hardware drivers on systems like that. The users process can not wreak havoc on the system, no matter how much it would misbehave in that context. Hardware typically has pretty clearly spelled out bounds and limitations, users processes operate with less rather than more privilege than a kernel side thread would and so have much less in terms of ability to wreck the system. As an extra bonus: a microkernel is small enough that formal verification is an option.