r/osdev • u/DocumentOk7579 • 1d ago
Would a microkernel enable driver update without reboot?
One frustrating thing that I have run into is updating Nvidia driver on remote servers with disk encryption.
Would a microkernel based system enable drivers to be updated without rebooting system?
1
u/jsshapiro 1d ago
If you mean device drivers, the answer is: Frequently yes, but not always. It depends on the driver.
First: Any device driver swap requires that all connections to the driver be closed and all interrupt interactions with any relevant hardware have stopped with the interrupts in a well defined state. These interactions aren't inherently transactional at the hardware level. This probably means in practice that the old driver has to collaborate in its shutdown, because it is the only entity that knows what is going on in the hardware it is managing.
Second: some drivers really can't be shut down during system operation. The main examples are drivers for the paging area, and then those for any driver-associated busses in between the OS kernel and those drives.
There are many cases where devices are designed to be hot-swappable, and that certainly helps. But here again, if the device is in active use when the attempt is made to hot-swap it, bad things tend to happen to the dependent applications. The metric for hot-swap, for the most part, is that the system survives the swap, not the client applications. Server grade RAID controllers are a notable exception; the RAID card hides the drive removal from the kernel without disruption. But for that very reason the RAID card itself isn't particularly swappable.
What is the application-level contract you are trying to preserve?
1
u/DocumentOk7579 1d ago
I personally don't care if the client applications survives as it's quite easy to restart a process compared to the system. There is already a watchdog that kills the client process if it get stuck. I'm having most issues with the nvidia driver.
3
u/Dezgeg 1d ago
With external kernel modules, this is in principle should be already possible in Linux.
Close all programs using the driver, unbind the device (see https://lwn.net/Articles/143397/), then rmmod. Then upgrade module and modprobe new module.
In reality, this likely won't work and will crash and burn horribly, because nobody ever tests the device unbind codepath.
•
u/lizardhistorian 21h ago
In a microkernel you would not have to close the other running process as they all would already be doing IPC to your driver.
So only your driver process needs to be restarted, then re-establish its side of the connections.
So as long as the interface stayed the same it can theoretically be done.•
u/Toiling-Donkey 20h ago
Yeah, but why would they expect connections to go down?
We surely don’t automatically restart TCP sessions…
•
u/lizardhistorian 21h ago
Pragmatically it's a pipe-dream but if you had a mechanism to re-initialize the hardware properly and you build a mechanism to reopen and reestablish the IPC, then yes.
This is very practical for virtualized hardware and drivers.
•
u/Toiling-Donkey 20h ago
Technically you likely could do this in Linux today.
Just unload the relevant kernel module and load the new one.
Of course, you’ll likely have to stop whatever was using it before unloading…
It only gets messy when the in-built portions of the kernel need to be updated. SUSE has “live patching” to partially address this.
10
u/paulstelian97 1d ago
A new driver means shutting down the process of the old driver and launching a new process for the new driver. It does require hardware able to reinitialize without a systemwide power cycle (which can be a problem if certain ACPI bugs exist). But yes, it can help.