Slashdot Mirror
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.
I just compiled 2.4.13 and reboot. Now I lost use of my keyboard. I wonder if 2.5 will do that.
I really hate Dan Patrick.
Going from the feel of my butt, not from benchmarks, XFS has been pretty stable on my desktop machine...however i've been experimenting with JFS, ReiserFS and currently ext3 and so far (remember no benchmarks) XFS seems the slowest of the 4 :-( Reiser or JFS seem to be the faster 2. None the less, when i get my new cisco dsl router and 24 port bay networks 24 port switch in and i turn my current router into a DNS/webcam/streaming mp3 server XFS will be my FS choice. Thank God for good coders! :-)
Derek Greene
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
interview's Keith Owens
There's no need for an apostrophe* in "interviews".
* The superscript sign ( ' ) used to indicate the omission of a letter or letters from a word, the possessive case, or the plurals of numbers, letters, and abbreviations. (ex dictionary.com)
deus does not exist but if he does
You need to fix the link to kbuild on sourceforge. =)
I wonder will the Linux kernel writers seriously look at incorporating support for the Advanced Configuration and Power Interface (ACPI) for the 2.5 kernel test release.
This could be very significant since ACPI allows for highly-automated system configuration, which is necessary if you want seamless hot-docking of external devices and ease of system upgrades.
Raymond in Mountain View, CA
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.)
www.eFax.com are spammers
From the interview:
This is excellent, and I hope more open source projects start to go this way. It's been known for a while that recursive make is a bad idea because it's inaccurate. Naive recursive makefile structures tend to miss stuff that needs to be built/installed and fixing that problem (usually with ugly hacks like make dep) generally results in building stuff that doesn't need to be built.
What Keith describes is a nice solution that provides the benefits of recursive make without the problems: Use per-directory makefile fragments which can be maintained locally, but automatically generate a complete, tree-wide makefile that is actually used for the build.
There are tools other than make that provide more elegant solutions, but given that they never seem to catch on, I'm happy to see that someone is applying the tool we have (make) correctly, for once.
I'm looking forward to this one.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I'm setting up a computer lab in my school using Redhat Linux. Its strictly for WEbsurfing, so I'm using IceWM and Netscape, which starts automatically, and I have an autologin script.
I was using Redhat 7.1 with XFS, but now that Redhat 7.2 came out with Ext3, I'm considering switching, and re-ghosting the machines.
Is Ext3 more stable than XFS?
Is the Kernel that came with the SGI distro of Redhat 7.1 stable? Or should I switch to 7.2 with Ext3? Which would I be better off with in the long run? Which will run the longest? And survive the most power outages? (this is going in the 7-8th grade building).
Thanks
I am kind of interested about his words on PRCS.
What exactly PRCS can do better than CVS in terms of maintaining multiple branches.
Are there any known big open source project currently using PRCS?
I read the paper, and it seems to basically say "it's pretty hard to get your dependencies right with recursive makes. If you don't get your dependencies right, then bad things happen. Therefore, recursive make is bad." It certainly is possible, if you're willing to put in any sort of effort, to get correct dependencies with recursive makes. I'm not going to comment on which method is better or takes less work, but the paper misrepresents just how bad recursive makes are.
It's slow too.
Life's a bitch but somebody's gotta do it.
... u answer questions in a interview with links :)
e /2000-Week-36/0575.html
8 65229622167&w=2
JA: Why does Linus refuse to include kdb?
Keith Owens: http://www.lib.uaa.alaska.edu/linux-kernel/archiv
JA: Why should it be included?
Keith Owens: http://marc.theaimsgroup.com/?l=linux-kernel&m=96
Linus is right, kernel debugers are not a good thing. You learn to fix the simptons no the dissease. If you want to code for the kernel you better learn it the hard way. ie. lots of hours rebooting and thinking what went wrong.
But its a good thing that a kernel debuger exists, it will help you understand how it works inside. But WONT help you FIX things.
bruj0-
http://securityportal.com.ar
BTW, anyone know where I can find an ext3 patch for 2.4.13? I'm also looking for the maestro3 module. They come with RedHat 7.2, but only on 2.4.9...
I read the paper, and it seems to basically say "it's pretty hard to get your dependencies right with recursive makes.
"Pretty hard" is an enormous understatement on large projects. When the project consists of thousands of source files it quickly becomes the case that *no one* knows what all of the dependencies are.
The whole point of make is that the dependency management should be automatic. make is able to understand the full dependency tree all at once, if you allow it to. Multi-pass makes can solve that problem, but it's very hard to know how many passes are required and the process does get to be very slow.
I'm not going to comment on which method is better or takes less work, but the paper misrepresents just how bad recursive makes are.
I'll comment on it, and my experience is that you're dead wrong; for big projects recursive make is really bad. At one company I worked for a few years back I was the lead developer on a large Unix project. The build system was based on a recursive make that kept degrading over time. We'd give someone the task of fixing it occasionally, and they'd go off and spend a week or so getting it cleaned up, but within a couple of months it would be wrong again, and all of the developers were having to do frequent complete builds (which took five hours). Eventually we took to rebuilding nightly, and everyone got used to the idea that if your were working and stuff started to misbehave badly that you just had to come back the next day. I finally decided that the whole thing was costing us way too much in productivity, so I rewrote the build system myself.
My goals were simple: I wanted a build system that (a) would do nothing if everything was up to date, (b) would not build anything more than once during a run and (c) would build correctly. Oh, and I wanted it to be easy to maintain. After three weeks of time I couldn't really afford to waste on a stupid build system I achieved my goals, but I had to write a shell script that checked a lot of the cross-module dependencies itself and directed the makes. Build times dropped from five hours to three hours and an up-to-date check took less than 10 minutes. I was very proud of myself.
On the suggestion of one of the other engineers I decided to try a global makefile, using distributed fragments; it would be easy to construct and easy to maintain, but I was sure it would be too slow. Still, it only took three days to set up, so I tried it.
To my surprise, an up-to-date check took 30 seconds the first time, and 5 seconds after that (because of file system caching). Overall, complete build times dropped to just over two hours. The makefile fragments were easy to maintain and the resulting build system was very robust. I disarded my other system, we switched to the global makefile and we never again had to waste days futzing with build processes.
So I have no doubt about which is better and which takes less work. A global make is fast, trivial to build and maintain, and always works properly. Recursive makes are often very slow, require maintenance and sometimes screw up, which wastes lots of effort. The *only* advantage a recursive make has is that it makes local builds deep in the directory tree a few seconds faster. Even that advantage is nullified by adding a few extra targets to the global makefile fragments and specifying a build target on the command line.
Recursive make is, simply, misuse of make. Tools are much more effective when used properly.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I noticed that kernel 2.4.10 are later now have the selection kernel debugger, available under the kernel hacking. So does the kernel now have a kernel debugger
Apparently not. The director of Sourceforge responded on Advogato about this rumour.
-Docvert converts MSWord to OpenDocument, clean HTML
That wasn't even funny. Pretty stupid in fact.
Derek Greene
Why is the above comment modded to zero? It's a relevant informational statement...
Derek Greene
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.
Without order, nothing can exist. Without chaos, nothing can be created.
1. It's Plaid Cymru. 2. They're not a terrorist group. They're a mainstream political party. In fact they're the one mainstream party in the UK calling for an end to the bombing of Afghanistan! Calling them a terrorist group is extremely libellous and I suggest you post an apology. 3. The Welsh nationalists are hardly a great revolutionary freedom movement. In a recent referendum 49% of the Welsh voted _against_ a national assembly! 4. How, exactly, are the Welsh being 'oppressed' pray tell?