Corolinth wrote:
I'm not disputing that it would be very complicated to build an operating system that allows one to update a video driver without a total system reboot. It's already a monumental undertaking just to build a modern OS. However, I would remind you that we are talking about electrical signals traveling back and forth inside of a box.
Well, actually it's not complicated at all. Mechanically, Windows has all of the necessary parts to do it (kernel module loading and unloading), but the video driver winds up being a wonky case because the GUI depends on the graphics driver (understandably so) and you can't restart the GUI without completely rebooting the OS (not so understandable). On *nix, this is layered better -- you can restart just the GUI (the X windowing system) without restarting the whole OS.
I'm totally with you about it being stupid that you have to reboot Windows for driver updates. My comments about complexity were with regard to solving
that problem, or the even more difficult problem of trying to make a video driver update completely seamless. That's...a horse of a different color.
Corolinth wrote:
If you go and install a new air conditioner in your home, you don't have to completely disconnect your house from the grid.
Yeah, let's run with this. I was trying to come up with an analogy involving cars, but it just wasn't working out. So, it's perfectly reasonable that you should be able to replace the A/C unit without disconnecting the mains (the Windows scenario), but per the Linux scenario, if you want to replace your A/C unit, it's still inevitable that at some point you'll have to turn off the old A/C unit, causing an interruption to that resource.
Could we solve this? Sure. There are two general approaches off the top of my head:
1) Redundancy -- i.e. some kind of internal "clustering" of the video driver that would let you do a rolling upgrade, so to speak.
2) Replace each "piece" of the driver one at a time while the driver is still running. This *could* be done if you were willing to commit to having a very consistent internal API between driver versions, and you have a very modular (and granular) design. Each part would also have to be capable of blocking, and being blocked by other parts of the driver. In this case, you could put each piece into blocking mode, wait for its queue to empty, replace it, and then unblock it.
Probably 2) makes more sense than 1) for internal processes like video drivers. But even so, why isn't this done? Well, the fact of the matter is that it's an exercise in over-engineering. It's not really about Moore's Law or anything like that. It's more a matter that restarting X is such a minor issue that there will
always be something more important for the driver programmer to do in terms of improving the driver experience.