Kernel Hacker Keith Owens On kbuild 2.5, XFS, More

Jeremy Andrews writes: "Kerneltrap interviews Keith Owens this week, an experienced kernel hacker who has long contributed to the Linux kernel. His contributions include updating ksymoops and modutils, both of which he maintains. He also works on kbuild 2.5. Earlier, he built the original Integrated Kernel Debugging patch. He's also working on kdb and XFS. Check out the interview." Lots of good information in here about things to expect in 2.5.

Comments

This is so cool

[Anton Anatopopov]

I have often wanted to have a go at kernel programming. I want to try and write some device drivers, but I am always too scared of this 'black art'. Its good to see someone taking time out to make it a bit more comprehensible for 'the rest of us'.

I'm wondering, do kernel developers use tools like vmware/plex86 to debug their running kernels ? It seems like we've come a long way since debugging with strategically placed printfs

Re:This is so cool

[SurfsUp]

I'm wondering, do kernel developers use tools like vmware/plex86 to debug their running kernels ? It seems like we've come a long way since debugging with strategically placed printfs

Vmware or plex86 could possibly be of some use, except that they're no good for debugging device drivers since the real devices are hidden behind a virtualization layer. For non-device driver work User Mode Linux is a more lightweight solution, and tracks the latest development kernels much more closely. An increasing number of the core developers are using User Mode Linux regularly.

For heavy debugging work on live kernels, kgdb is the perferred solution, with a serial cable link to a test machine. It takes a little more work to set this up and you need two machines. Kdb is a simpler debugger that can be patched into the kernel, useful for tracking down elusive kernel problems. It's included by default in SGI's XFS patch and pre-patched kernels.

There are some great tools available including LTT, the Linux Trace Toolkit and various lock-monitoring patches. Unfortunately, most driver development is still being done by the printk/reboot method. If this is your preferred method, make sure you install a journalling filesystem unless you like spending most of your time watching fsck work.

--
Daniel

It's a shame about Linus's opinion on kdb

[wowbagger]

While I can certainly understand Linus wanting to encourage would-be kernel developers to learn "a gram of analysis is worth a kilo of debugging", I do wish he would consider one area in which a kernel debugger is invaluable - hardware integration.

"In theory, there is no difference between theory and practice. In practice, there is." In hardware development, there is the theory of what the hardware documentation says the chip will do, and then there is the practice of what it actually does. DMA's don't, interrupts stick, registers report old data. Obviously, you START by writing a user space app that pokes at the hardware (and this is one area in which Linux is head and shoulders above WinNT - there is NO way for a user space app to access hardware in NT, while in Linux you simply have to be root), but when you finally need to hook interrupts, allocate DMA buffers, etc., you need a debugger that can look at these events.

Also, when porting to other CPUs, you sometimes need to see what is going on at the hardware level, and how it affects the drivers in the kernel.

Yes, allowing debugging without analysis is bad. But throwing us back to the stone knives and bear skins era just to encourage hardier folks is an overreaction. Sure, make a KDB kernel bitch and moan during startup. Make it only allow root access, not normal user access. Force all file systems to run in full sync mode. But please don't make debugging buggy hardware any harder than it needs to be.

(Now, if only AMD would add a JTAG debugger to the Athlon chip, I'd be a happy man.)

We switched back from ReiserFS to ext2...

[parabyte]

...after a series of filesystem corruption on four different Machines using different Versions of ReiserFS with many different Kernels from 2.4.2 to 2.4.12, with different SCSI disks as well as on several IDE drives, and systems ranging from a Dell Inspiron 8000 Notebook over some homegrown single PIII, dual PIII's on different Mobos to a Dell dual P4 Rambus system. For the last twenty years I have never seen something like this:

After power cuts on frozen development systems it regularly happened that files written minutes ago were completely corrupted; they were there, but just garbage in them; what you have written explains what probably happened; however, it troubled me that files written minutes ago were affected. What really upset me to throw out ReiserFS on every machine was when after a crash every File I created within the last two hours was destroyed; I never thought a Filesystem might take out many hundred files with such a precision. Even if I would not blame ReiserFS for this disaster (I Do), I consider it as completely unacceptable that all this happened without the slightest warning; no entry in the syslog, no boot message, nothing. ReiserFS pretended everything is fine. Do you have any explanation for such an behaviour, and are such effects just the downside for using a journaling fs, or is it something ReiserFS specific ? What added to my loss of confidence into this ReiserFs was that a few months ago reiserfsck did core dump when I tried to repair a file system that showed strange behaviour, which I regarded as exceptional behavior at that time.

For now I switched back to ext2 and feel pretty good to see a thorough filesystem check after a crash. I do not remember much trouble using XFS with IRIX, but I have no experience so far with any journaling fs on linux exept those mentioned above. So do You have any recommendation for a filesystem on a unstable development system, where I can not sacrifice too much performance, but need at least confidence into the integrity of my fs ? (I did not loose much data, but It easily takes a few hours to bring back a system from the backups, but an unnoticed damage to vital files can drive you crazy). p.