I suspect in the long run that one will be settled in favor of the microkernel, but it will take a long long time to get there. Missed chance if there ever was one, but I can see some ulterior motives to keep the kernel as complex and hard to contribute to as possible. If everybody could write drivers then where would be the glory in that...
Yes you are, but that's fine. I totally see why the difference between 'can' and 'actually does' is lost. The reason for that is simple: device driver writing on a monolithic kernel is something of a black art, even with all the tools we have at our disposal today. 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, but other than that you would not be able to tell the difference. Debugging would be almost as easy as debugging any other user process. You could use a whole slew of high level languages to do your device driver writing. If the interpreters on the system would take care of the lower levels of interacting with the kernel to deal with IO and/or interrupts then you could do your device driver writing in interpreted languages.
But, you'll have to wait a little longer to be able to do that. Or try to locate a copy of QnX...
> 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.
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.
I suspect in the long run that one will be settled in favor of the microkernel, but it will take a long long time to get there. Missed chance if there ever was one, but I can see some ulterior motives to keep the kernel as complex and hard to contribute to as possible. If everybody could write drivers then where would be the glory in that...