Truly Free drivers could use a stable API too

Posted Nov 10, 2005 18:26 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

Depending on your precise definition of "reboot" it's also possible with newer kernels to run the kexec wrapper around the kexec() system call
and thus load a new kernel without a firmware reboot. (Also available
with the old 2-kernel monte patches and utility).

Of course all user processes are killed through a kexec() ... and all
devices are re-initialized by the new kernel. Thus this is a "reboot"
in that sense of the term.

Combine that with some Mosix and Xen like process checkpointing and suspension and you could very well devise a Linux system that would not
have to be "rebooted" in order to switch in a new kernel.

But it's quibbling to compare the necessity of rebooting into a new kernel
with the infamous reboots required for trivial system settings in earlier versions of MS Windows. I used to have a poster with a genuine appearing MS Windows GUI dialog that read:

You have moved your mouse.
A system reboot is required for this change to take effect.
[Ok]

JimD

Posted Nov 10, 2005 22:52 UTC (Thu) by Duncan (guest, #6647) [Link]

>> To install a new kernel you have
>> to reboot - very Windoze like :-(
>
> Well, to install a new card you
> have to reboot too[.]
>
> Now for USB stuff and network protocols[...]

Actually, for hotpluggable stuff like USB, there are kernel modules.
Kernel modules can be compiled separately, against the codebase used to
compile the running kernel, and can then be modprobed, without rebooting.

As for closer to the core hotpluggability, memory and CPUs and the like,
the kernel isn't quite there yet, but support is actively being worked up
and is already there to some degree. For this sort of support, modules
aren't generally needed, because support for a base level will be compiled
in and additional CPUs or memory use the existing support.

Of course, one still has to reboot (or kexec) to a new kernel if switching
to hardware of a different architecture. However, I don't know if
anything supports that, and the call for such support isn't that great,
anyway, tho it could be useful in certain high availability situations.

BTW, the user mode drivers comments someone made are a good idea, as well.
There's nothing stopping that (tho more integrated/direct kernel support
in some cases would be very useful, think fuse implementation before and
after the kernel support for it), and indeed, the kernel's GPL preamble
specifically states that the restrictions of the GPL do NOT apply to
userspace, so binary drivers are with no controversy completely legal
there (altho there remains disagreement of whether they are /moral/, but
it's the usual controversy of whether /any/ binary-only code is /moral/).
The problem of course is the performance bite. It's fine in some cases,
particularly where there's direct kernel support for the userspace drivers
as with fuse, but would suck for something like NVidia's video drivers.
Very good point made, none-the-less.

Duncan