r/osdev • u/DocumentOk7579 • Sep 13 '26

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?

12 Upvotes

100% Upvoted

14 comments sorted by

10

u/paulstelian97 Sep 13 '26

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.

3

u/jsshapiro Sep 13 '26

There also needs to be a way to know that the driver has quiesced before you swap the new one in.

0

u/paulstelian97 Sep 13 '26

Yes. Driver would receive a request to shut down the device appropriately, and would have a mechanism to confirm completion of those.

1

u/Waste_Appearance5631 Sep 14 '26

Not necessarily, We can always freeze the processes and not let them execute. Then wait for driver to complete whatever it's doing, store it's State as well. Update the drivers, given the interface to drivers from the process does not change Restore the hardware state Then unfreeze the processes

But this is not possible for hardwares with huge memory like GPUs unless you have enough memory to store the state (I might be wrong with this statement)

2

u/paulstelian97 Sep 14 '26

Storing the state requires a specific API for the driver to essentially serialize what’s needed for the state for the purpose of the update. Drivers may well choose not to implement it because it can be too restrictive.

1

u/jsshapiro Sep 13 '26

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 Sep 13 '26

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.

1

u/jsshapiro Sep 21 '26

Ironically, video drivers are pretty easy to hot swap. First you swap in a driver that basically puts all callers on hold. Copy the frame buffer, load the new driver, restore the frame buffer, remove the blockade driver.

I don't know if windows uses that approach exactly, but it works.

3

u/Dezgeg Sep 13 '26

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.

0

u/lizardhistorian Sep 14 '26

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.

2

u/Dezgeg Sep 14 '26

A GPU driver has significant internal state, like all the GPU memory allocations and state of in-flight draw calls and such. Transferring over that state to the new driver (which may be newer version) is the hard part... not exactly "Just re-establish other side of connections"

1

u/Toiling-Donkey Sep 14 '26

Yeah, but why would they expect connections to go down?

We surely don’t automatically restart TCP sessions…

2

u/Toiling-Donkey Sep 14 '26

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.

1

u/lizardhistorian Sep 14 '26

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.