Re: live kernel upgrades (was: live kernel patching design)

[Ingo Molnar]

* Jiri Kosina <jkosina@xxxxxxx> wrote:

> [...] We could optimize the kernel the craziest way we 
> can, but hardware takes its time to reinitialize. And in 
> most cases, you'd really need to reinitalize it; [...]

If we want to reinitialize a device, most of the longer 
initialization latencies during bootup these days involve 
things like: 'poke hardware, see if there's any response'. 
Those are mostly going away quickly with modern, 
well-enumerated hardware interfaces.

Just try a modprobe of a random hardware driver - most 
initialization sequences are very fast. (That's how people 
are able to do cold bootups in less than 1 second.)

In theory this could also be optimized: we could avoid the 
reinitialization step through an upgrade via relatively 
simple means, for example if drivers define their own 
version and the new kernel's driver checks whether the 
previous state is from a compatible driver. Then the new 
driver could do a shorter initialization sequence.

But I'd only do it only in special cases, where for some 
reason the initialization sequence takes longer time and it 
makes sense to share hardware discovery information between 
two versions of the driver. I'm not convinced such a 
mechanism is necessary in the general case.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/