4 ms·
That's the big unknown question with microkernels. It was (in the 90s) a reasonable theory that a microkernel could be much more robust and secure and easy to d
by tlb 3y ago
That's the big unknown question with microkernels. It was (in the 90s) a reasonable theory that a microkernel could be much more robust and secure and easy to develop than a monolithic kernel.
It would be more robust because individual services could crash and restart. That could really work for, say, WiFi drivers. It doesn't quite work for disk drivers or the file system, since how do you even restart something without a file system?
It would be more secure because drivers would live in isolated memory spaces. So a non-critical piece like a printer driver couldn't read memory from something more critical like a file system. Part of what changed since microkernels were originally proposed is that drivers are often split into low- and high-level parts. So a printer driver in Linux consists of a standard USB or network driver in the kernel, plus a user-level driver that can be worked on like a microservice. And the WiFi driver is a low-level driver plus wpa_supplicant running at user level. The USB and network drivers are shared with critical services, so you can't easily restart them anyway.
It would be easier to develop because you can restart just the piece you're working on without rebooting the whole kernel. That's a plausible argument, but somewhat undermined by HURD taking 30 years to develop. But there were many other reasons for that.
I guess the way to convince yourself one way or another is to try writing a driver for both.
- taeric 3y agoRight, I remember parts of that history. Memory protection schemes in other operating systems didn't exactly stay static, though. And a ton of the optimizations that monolithic kernels (mostly looking at windows) did went away just with the lack of need for them. Heck, at the time, Mac wasn't even a preemptive multitasking operating system. And "drivers" could just restart is laughable with a role play of it. Ok, your wifi driver restarted. What are the protocols to get everyone caught up between that driver and your application for what messages were lost and the messages that are now arriving? This is effectively no different from any distributed application where similar things are unsurprisingly hard to achieve well. I'll state that I think this is a laudable goal. And I'm happy to see people working on it. Would be thrilled to be shown I'm wrong.
- rcxdude 3y agoIt can be done though: see what Windows has managed to do with graphics drivers. I've experienced a full crash of the graphics driver and windows just restarted it and kept on trucking, the only casualty being the 3D application which presumably triggered the crash. It's not just a matter of sprinkling the microkernel architecture on your system, but something like that is a prerequisite.
- strbean 3y ago> Ok, your wifi driver restarted. What are the protocols to get everyone caught up between that driver and your application for what messages were lost and the messages that are now arriving? TCP?
- taeric 3y agoDoesn't fully help? Could actually be more difficult if you let the driver do the TCP ack. And you are likely going to back yourself into a situation where you need TCP between the application and the driver... Remember, at that point, it is just a message pass, as well. There is a good article somewhere about how you have to do end to end for any of this to really work.
- rcxdude 3y agoIf your network stack is running isolated to your wifi driver (with the interface being frames to send and receive), it's fine: the network stack just sees some dropped packets the same as if something else dropped them. If your network stack with your TCP state crashes, then it's a bit trickier: the connection will likely be dropped, which requires an application-level retry, which also will generally already exist to deal with more significant network issues. I don't think you've picked a great example for this kind of problem.
- taeric 3y agoI would assume that the TCP state would be part of the "networking service" that is isolated from my application. As such, I'm assuming the more complicated situation there. That said, I don't make too big of a defense of networking being a bad choice. At large, that is literally where you have to do distributed computing anyway; so, agreed a lot of it will be covered for a lot of applications. I was trying to stick to the examples others chose as I'm not really trying to "gotcha" to anyone. My main point was honestly more about how similar that is to how we are today. If you were in a microkernel, is it any easier? Because that is the original goal post here. I do further question why you'd want to do that for every subsystem interaction, and if you really want to have to redo all kernel context swaps and local message passes if something went wrong locally.