Linux Kernel 2.2.6 Released

Some guy named Chris was the first to write in to say Linus has blessed us with 2.2.6. Additionally, Alan has already posted 2.2.6ac1, and the mirrors will hopefully be synced by now. Cutting Edge Linux has the changelog.

Comments

2.3.x ... for what?

[Frater 219]

I see a lot of people here saying they expect all manner of neat features in the 2.3.x experimental kernels. However, I don't see any inkling of what these neat features might be.

One thing I, for one, would like to see, is for the FreeS/WAN kernel patches to become part of the regular kernel distribution..

What other features do we need/want in a kernel?

2.3.x

[David E. Smith]

Well, actually, that's a long story. Since this will probably get moderated out of existence anyway, why not tell it?

From 2.0.33 to 2.0.34, both the SCSI and PPA subsystems underwent some hefty revisions. The end result of such was that, for all kernels newer than that (including most of the 2.1 series, 2.2pre, and all 2.2 kernels to date) cause interesting kernel panics whenever I try to mount my Zip drive.

I spent a couple months in close touch with the PPA/parport people, and some with the SCSI people. We simply can't resolve the problem. Yes, I sent in copious bug reports (under an old email address, no less). Yes, I did -DDEBUG for nearly the whole damn kernel (as the problem occasionally manifests itself in places like the VFAT file system, for no reason we understand). No, we don't have a bleepin' clue what's up.

Okay. Go give this a low score, modkins. It deserves it. It's a rant, pure and simple. But it felt realllly good.

So why not work on the feature that we REALLY want

[Byter]

...the ability to upgrade our kernel without rebooting! :-)

From what I can see, the kernel image is copied bytewise into memory on boot-up. Once we're finished with compiling a new kernel, why not have the old kernel copy a mini-kernel into memory that would do nothing but overlay the old kernel image in memory with the new kernel image, and then pass control to the new kernel? :-).

(Of course, we would have to find a way to keep track of the current state of the kernel, (probably by swapping the kernel structures to a file, and then swapping those structures back in to the new kernel image))

If we disabled all interrupts when we switched kernels, and suspend all processes (which should be easy..since we're running in ring zero)..why wouldn't this work?

Think about the massive benefits of this! Think about the uptimes we could have with this! :-)

That might seem easy, but it's tough

[cesarb]

The Right Way to do this is to make a full dump of the system state (processes etc.), load the new kernel in the memory (compressed), install a trampoline in memory, and jump to it. The trampoline would:

a) Do the required hardware shutdown (to avoid undetermined state). Doing this without breaking a modem connection is left as a exercise to the reader.
b) Disable NMI and interrupts
c) Dump the kernel structures (ps tables, etc)
d) Change the structures to match the format in the new kernel (the 1st hard step)
e) Load the new kernel with a special flag. It will initialize, reinitialize the hardware, check the flag and jump back to the trampoline.
f) The trampoline disables NMI and interrupts (again)
g) The trampoline restore the kernel structs (now in the new kernel's format), calling special __initfunc functions in the kernel to alloc memory and setup the new values. It also reloads the modules the same way.
h) The program states is undumped (the 2nd hard step) by the kernel (called from the trampoline).
i) The trampoline jumps to the kernel, which cleans up and frees the trampoline and its data.
j) The kernel sends a SIGKUPD (kernel update) to all processes and runs schedule.
k) The update program notices the signal, and call the bootloader to setup the boot block (so if you have a power outage here the kernel to run will be the new one).

Note: the process dumps are to the disk (root directory, probably)

The hard parts:
0. Generating the trampoline.
1. Converting the kernel structures (doing this automatically, with version gaps of 2-3 minor numbers, is pretty hard).
2. Restoring the processes state. Some sutble things have changed, and will crash many processes. The signal to make them re-exec themselves helps a bit, but legacy (ahem) apps will suffer.

The 'hard part number one' is the worst one.

Here's what you (probably) need..

[Telsa]

Wow. A question I can answer. That's rare. You probably want to look at Joseph Pranevich's list of changes which was put out in January for 2.2.0.

I found this by going to Linux Weekly News and looking through the archives for the week that 2.2.0 came out. Hope this helps.

when SHOULD you update?

[schmack]

Is there an official line on when users should or should not upgrade their kernel?

With more an more Linux users with less experience -- some might have only known enough to fumble their way through a RedHat5.2 install -- there needs to be guidelines.

Is it a case of don't fix it if it ain't broke or are there new features to be reaped from newer kernels?

I think this must be an important area to be marketed in order to forge ahead with world domination!

when SHOULD you update?

[NetHunter]

First, there is the Kernel-HOWTO (on the LDP)
Second, usualy, you shouldn't upgrade if the new kernel doesn't have something you need. Usualy, revision kernels have mostly fixes (In 2.2.6, the revision is 6), most updates are in the development kernel, (2.1, was for the 2.0 stable,but it hasn't started yet for 2.2) and in minor updates, like 2.0 to 2.2. Anyway, you should read the Kernel-HOWTO

What's new?

[jeetendra]

Hi everyone. Okay I'm not new to Linux but I'm no programmer. I've upgraded to kernel 2.2.6 -- probably due to my M*cr*s*ft mind-set that takes over from time to time -- upgrade! submit! comply!
But in all honesty I have *no* idea how the 2.2 series differ from the 2.0 series RedHat ships with.
Could someone here (strip sarcasm ; cat witty_asides > /dev/null) please explain the advantages/differences of 2.2.6 over, say, 2.0.36...
Thanks! May segfaults never darken your monitor...