Linux 2.6.26 Out

diegocgteleline.es writes "After three months, Linux 2.6.26 has been released. It adds support for read-only bind mounts, x86 PAT (Page Attribute Tables), PCI Express ASPM (Active State Power Management), ports of KVM to IA64, S390 and PPC, other KVM improvements including basic paravirtualization support, preliminary support of the future 802.11s wireless mesh standard, much improved webcam support thanks to a driver for UVC devices, a built-in memory tester, a kernel debugger, BDI statistics and parameters exposure in /sys/class/bdi, a new /proc/PID/mountinfo file for more accurate information about mounts, per-process securebits, device white-list for containers users, support for the OLPC, some new drivers and many small improvements. Here is the full list of changes."

Kernel Debugger

[wvdmc]

While the debugger is, in fact, remote, it appears that perhaps the Linux Kernal really is JUST NOW getting an actual debugger. From TFA:

For many years Linux has not included a kernel debugger. Linus Torvalds vetoed them for years, for reasons that he explained quite well in a know email: "When things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger [...] I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_." Despite of those objections, many people wanted a debugger and KGDB is finally going in. It's a remote debugger, it needs two machines. x86 and sparc machines are supported

Re:Kernel debugger?

[something_wicked_thi]

A kernel debugger is a program you can run from one computer, generally via a serial patch cable or some such, that lets you step through the kernel code running on another computer. It's like a normal debugger, but remote.

Linux has had kernel debuggers for years, but Linus never wanted it in mainline [linuxmafia.com], so it was always a patch, and sometimes didn't work on the latest kernel. Now, it's part of the kernel (I don't see any links to why Linus changed his mind, but you might be able to find something on LKML if you look).

Anyway, I think this is good news. I understand why Linus never wanted a debugger in the kernel, but I disagree with him on two points. First, even developers who have a good understanding of the code can get work done faster if they use a debugger. Using a debugger does not automatically relegate you to someone who doesn't have a good understanding of things, as Linus would have you believe (i.e. there's a difference between needing a debugger and being more productive with a debugger).

Second, there are a lot of people these days who just fix bugs, or just want to debug their own tiny kernel patch. I.e. people who don't have a full understanding of the system but who need to get something done. It's good that these people are now first-class citizens. They likely will never write a new kernel subsystem, but maybe they'll fix a few bugs and make life better for the rest of us.

Re:Clever new tools for kernel config

[Zarhan]

Aye - would be great if there would be tool that I could eg. say "Ok, right now, at this moment, I have all my hot-pluggable USB/PCI devices plugged in, please detect and configure the options as needed". After all, that's what I do with a new comp: use lspci and similar tools to find out what's in the guts of the machine and then set options appropriately in menuconfig.

Re:Real writeable NTFS?

[something_wicked_thi]

Not sure why it isn't in the kernel.

Because it doesn't need to be. Really, that's all there is to it. The old one took a long time to develop because kernel code is harder. The only real reason why you'd want an in-kernel driver is if you wanted to boot off of NTFS. The in-kernel driver is good enough to let you do that via a loopback file on the NTFS volume, so the rest can be in userspace.

Apple uses that, too, and I don't hear people complaining about Apple's support for NTFS. People who still complain about this are living in the past, or are hitting one of the few remaining strange corner cases that aren't yet supported (and I very much doubt you are).

Re:Does it disturb anyone else?

[Eudial]

It adds support for read-only bind mounts, x86 PAT (Page Attribute Tables), PCI Express ASPM (Active State Power Management), ports of KVM to IA64, S390 and PPC, other KVM improvements including basic paravirtualization support, preliminar support of the future 802.11s wireless mesh standard, much improved webcam support thanks to a driver for UVC devices, a built-in memory tester, a kernel debugger, BDI statistics and parameters exposure in /sys/class/bdi,

Does it disturb anyone else how many words the bsdm & linux kernel community have in common? (this is not a troll).

Frankly, I blame IBM.

Well, the kernel sources are (or were) pretty explicit in their sexual deviations. I remember several occurrences of the following comment: /* Fuck me gently with a chainsaw... */ in the 2.4 tree.

It shouldn't be hard.

[jd]

At least, to do a pre-configuration tool. You can currently list the processor(s), scan many of the physical and virtual busses, discover nearby network resources, etc. If that information were to be collected and then compared with "best practice" values for configuration options, it should be possible to set up many of the kernel options automagically. Not all, perhaps, but many. If you want something really sophisticated, you could do this as a two-pass thing. First pass uses "best practice" values and enables all of the kernel's profiling options. Second pass tweaks those values for the specific hardware being used using the profiling information, and disables all non-essential debug/profile options.

This would not build a "perfect" kernel, but it should produce something damn close, especially if the user is asked to supply information on anything that is uncertain or which cannot be deduced from the information that's discoverable or collectible.

There are also kernel patches, such as WEB100, which can tune some elements of kernel operation when a system is in use. If you add that into the mix, then you end up with something that is highly customized for the user without the user having to do more than the minimum of customization.

Re:Does it disturb anyone else?

[kwabbles]

On my 2.6.24 box: :/usr/src$ egrep -ir "( fuck)|( shit)" *

linux-headers-2.6.24-16/include/asm-mips/mipsprom.h:/* More PROM shit. Probably has to do with VME RMW cycles??? */
linux-headers-2.6.24-16/include/asm-sparc64/system.h: /* If you fuck with this, update ret_from_syscall code too. */ \
linux-headers-2.6.24-16/include/linux/netfilter/xt_limit.h: /* Ugly, ugly fucker. */
linux-headers-2.6.24-16/include/asm-m68k/sun3ints.h:/* master list of VME vectors -- don't fuck with this */
linux-headers-2.6.24-16/include/asm-cris/arch-v32/spinlock.h: * writers) in interrupt handlers someone fucked up and we'd dead-lock
linux-headers-2.6.24-16-generic/include/asm-mips/mipsprom.h:/* More PROM shit. Probably has to do with VME RMW cycles??? */
linux-headers-2.6.24-16-generic/include/asm-sparc64/system.h: /* If you fuck with this, update ret_from_syscall code too. */ \
linux-headers-2.6.24-16-generic/include/linux/netfilter/xt_limit.h: /* Ugly, ugly fucker. */
egrep: linux-headers-2.6.24-16-generic/include/linux/linux: No such file or directory
linux-headers-2.6.24-16-generic/include/asm-m68k/sun3ints.h:/* master list of VME vectors -- don't fuck with this */
egrep: linux-headers-2.6.24-16-generic/include/asm/asm-x86: No such file or directory
egrep: linux-headers-2.6.24-16-generic/include/asm-x86/asm-x86: No such file or directory
linux-headers-2.6.24-16-generic/include/asm-cris/arch-v32/spinlock.h: * writers) in interrupt handlers someone fucked up and we'd dead-lock