1 |
"Boyd Stephen Smith Jr." <bss03@××××××××××.net> posted |
2 |
200705190231.33752.bss03@××××××××××.net, excerpted below, on Sat, 19 May |
3 |
2007 02:31:27 -0500: |
4 |
|
5 |
> On Friday 18 May 2007 23:45:42 Peter Davoust wrote: |
6 |
>> Actually, I wanted to ask a some what unrelated question as well: I've |
7 |
>> heard it's possible to update kernel without rebooting, and while I'm |
8 |
>> not sure of the advisability, I'm getting things to work here and I'd |
9 |
>> like to not have to reboot my computer so many times. Besides, it just |
10 |
>> sounds cool. Could someone tell me how to do it? |
11 |
> |
12 |
> I've done it before via kexec, but I don't remember exactly how. Google |
13 |
> for: linux kexec how-to |
14 |
> and you should get some useful links. |
15 |
|
16 |
I'm going to go out on a limb here (but not so far, I think), and say |
17 |
most folks shouldn't be worried about kexec at this point. There are a |
18 |
lot of unpredictables in terms of hardware state once the new kernel is |
19 |
started, many of which the kernel isn't yet expecting (it expects to |
20 |
start with everything in a known or just initialized state) or prepared |
21 |
to deal with, and most folks won't be prepared to deal with the potential |
22 |
crashes and even possible data loss, if things don't go quite right. |
23 |
|
24 |
kexec is coming along (just with kernel 2.6.22-rc1 a critical piece was |
25 |
placed for x86_64/amd64 users, an x86_64 kernel can now be compiled as |
26 |
relocatable, according to the changelog), but I don't believe any |
27 |
involved kernel hacker would tell you it's ready for ordinary prime-time |
28 |
use, yet. I'd say another six months to a year, anyway, maybe more if |
29 |
development focuses on other areas more and less on kexec. |
30 |
|
31 |
Without kexec, in general, no, one has to reboot to make use of a new |
32 |
kernel or its features. However, it IS possible to build modules and |
33 |
insert them into a running kernel. Of course, that works best if it's |
34 |
modules for the same kernel and using the same CFLAGS. I'm sufficiently |
35 |
cautious not to even consider otherwise, but it does sometimes work (and |
36 |
in fact, with proprietary closed source modules, /must/ work, to /some/ |
37 |
extent, but I don't run those, either). So yes, even without kexec, if |
38 |
all you are doing is building additional modules, particularly if it's |
39 |
the same kernel sources and cflags, you should be able to load those |
40 |
modules in the running kernel without damage or indeed undue risk. The |
41 |
kernel is in fact designed for such module loading. (The big risk is in |
42 |
unloading modules, particularly in /force/ unloading, because it can |
43 |
create serious race and unknown state conditions. There's still an |
44 |
option for forced unload, however, with the caveat that it's discouraged, |
45 |
and only for use where the alternative would be reboot anyway, and the |
46 |
risk of kernel instability is considered less of a loss than the reboot |
47 |
might be.) |
48 |
|
49 |
-- |
50 |
Duncan - List replies preferred. No HTML msgs. |
51 |
"Every nonfree program has a lord, a master -- |
52 |
and if you use the program, he is your master." Richard Stallman |
53 |
|
54 |
-- |
55 |
gentoo-amd64@g.o mailing list |