Re: Availability of kdb
On Sun, 10 Sep 2000, Horst von Brand wrote: > I've found more bugs by "working half crippled" (as you call it). I do > agree with Linus that people who rely mainly on debuggers for finding and > fixing bugs are on the whole bad programmers, I've had to deal with more I've resisted from participating this thread but as it seems to drag forever, what the heck (probably a bad move). Your argument has the flaw that all programmers using debuggers are bad programmers, programmers who have no self-discipline, no guts to actually find out what was wrong. Just as any tool, debuggers can be abused but they should not be condemned on that basis alone. On another note, I think even those bad, lazy programmers are intelligent enough to find kdb on the net and patch it into their kernels. The mere availability of the tools then should be enough for explosion of bad code but has this happened? On the other hand, those people who are not knowledgeable enough to mess with patches, system administrators or end users have no access to the tools when they need it. For example for a driver author who is trying to debug a problem he can't reproduce by himself, it would be useful to instruct the bug reporter to enter the debugger, execute these commands and mail the results back to himself. Debugger would simply be a tool to get wider knowledge of the kernel state than a simple oops dump. Dave Miller explains his methods for finding and fixing bugs in the code which seem logical enough but who gets to decide what's enough knowledge of the kernel state? Currently it is oops and nothing but the oops. If taken to its logical extreme, one could argue that oopses should be removed too. Afterall they perform the same function as printing the register dump and the stack backtrace in a debugger would. -- D. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Sun, 10 Sep 2000, Horst von Brand wrote: I've found more bugs by "working half crippled" (as you call it). I do agree with Linus that people who rely mainly on debuggers for finding and fixing bugs are on the whole bad programmers, I've had to deal with more I've resisted from participating this thread but as it seems to drag forever, what the heck (probably a bad move). Your argument has the flaw that all programmers using debuggers are bad programmers, programmers who have no self-discipline, no guts to actually find out what was wrong. Just as any tool, debuggers can be abused but they should not be condemned on that basis alone. On another note, I think even those bad, lazy programmers are intelligent enough to find kdb on the net and patch it into their kernels. The mere availability of the tools then should be enough for explosion of bad code but has this happened? On the other hand, those people who are not knowledgeable enough to mess with patches, system administrators or end users have no access to the tools when they need it. For example for a driver author who is trying to debug a problem he can't reproduce by himself, it would be useful to instruct the bug reporter to enter the debugger, execute these commands and mail the results back to himself. Debugger would simply be a tool to get wider knowledge of the kernel state than a simple oops dump. Dave Miller explains his methods for finding and fixing bugs in the code which seem logical enough but who gets to decide what's enough knowledge of the kernel state? Currently it is oops and nothing but the oops. If taken to its logical extreme, one could argue that oopses should be removed too. Afterall they perform the same function as printing the register dump and the stack backtrace in a debugger would. -- D. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] streamfs file system
I'd like to announce the availability of streamfs filesystem for the linux-2.4.0-test8 kernel. Streamfs is a special purpose file system for Linux geared towards audio/video editing and other streaming media needs. It is special purpose in the sense that only limited number of regular files (or tracks) are supported. However these are guaranteed to be non-fragmented. Streamfs also tries to take advantage of the locality of reference by interleaving the tracks together on disk. In addition streamfs still supports a limited amount of meta information on the partition such as directories and symlinks. Tracks are stored on disk by interleaving them together. Below is an example of the on-disk layout in the case where there are four tracks on the filesystem with a track fragment size of one block. 0 4 8 12 16 20 ---+---+---+---+---+--- AAA|BBB|CCC|DDD|AAA|... ---+---+---+---+---+--- This filesystem was mostly done to get familiar with VFS and filesystems in general. The goal was to make a very simple filesystem but yet it should be useful. The former I think succeeded well, the whole code is just 2000 lines when counted with wc. Having tested and benchmark quite a lot during the last week I can't say I'm sure about its usefulness. There seems to be a definite advantage over ext2 in hdrbench [1] tests but it isn't certain that this advantage outweighs the extra complexity and the limitations of which audio-dev folks expressed their concern. Streamfs has been a good learning experience and as such has already served its purpose for me so I think I'll let the user feedback to decide whether further effort is warranted. More information and download: http://www.cs.helsinki.fi/Aki.Laukkanen/streamfs.html References: [1] http://www.linuxdj.com/hdrbench/ -- D. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
