login
Header Space

 
 

Jesper Juhl

Quote: The Burden of Debugging

April 11, 2008 - 6:01pm
Submitted by Jeremy on April 11, 2008 - 6:01pm.

"The way I see it, the burden of debugging and fixing bugs is mainly on the developers of the code that breaks. You can't blame users for using the code, triggering bugs and then reporting the breakage. Users who report bugs are doing us all a great service regardless of their ability or willingness to do more work than just the initial report."

— Jesper Juhl, in an April 10th, 2008 message on the Linux Kernel mailing list.

Linux: Moving 4K Stacks Forward

August 16, 2007 - 4:42pm
Submitted by Jeremy on August 16, 2007 - 4:42pm.
Linux news

In a series of 5 patches, Jesper Juhl propsed moving 4K stacks from a debug feature to a non-debug feature, defaulting it to be enabled in the -mm tree. He referred back to a lengthy earlier discussion in which he had proposed making 4K stacks the default in the mainline kernel, then added:

"Based on the comments in that thread I conclude that 4KSTACKS are not really considered a debug-only feature any longer, but the time is not right (yet) to make them the default - and it's certainly not yet the time to get rid of 8K stacks."

"In that thread I promised to provide some patches that would lift 4KSTACKS out of debug-only feature status, which is what the first two patches in this series do. I also said I would provide a patch to make 4KSTACKS 'default y' to get more testing, but restrict that patch to -mm - that's the fifth patch in this series. Patches 3 & 4 in this series move the config option out of the Kernel hacking menu and into Processor types and features".

Linux: Translating Kernel Documentation

June 11, 2007 - 6:36am
Submitted by Jeremy on June 11, 2007 - 6:36am.
Linux news

The translation of a some kernel documentation into Japanese led to a discussion as to whether or not it was appropriate to include translated documentation with the kernel source code. One concern that was expressed was that as the number of included translations grows, so would the size of the kernel. Another concern was the liklihood that as time passes the various translations might become out of date. Jesper Juhl suggested one workaround, "since the common language of most kernel contributors is english I personally feel that we should stick to just that one language in the tree and then perhaps keep translations on a website somewhere. So the authoritative docs stay in the tree, in english, so that as many contributors as possible can read and update them."

Greg KH noted that there were a number of files in the kernel that change infrequently and that he would like to see included, "I really do want to see a translated copy of the HOWTO, stable-api-nonsense.txt, and possibly a few other files in the main kernel tree (SubmittingPatches, CodingStyle, and SubmittingDrivers might all be good canidates for this.) These files change relatively infrequently (the HOWTO file has had only 7 changes in 1 and 1/2 years, and they were very minor ones) and should be easy for the translators to keep up with."

Linux: Cleaning Up Per The Kernel Coding Style

May 11, 2005 - 7:02pm
Submitted by Jeremy on May 11, 2005 - 7:02pm.
Linux news

Jesper Juhl submitted a small patch to bring the kernel/module.c source file closer in line with the kernel's CodingStyle document. Specifically, he quoted from the CodingStyle document, "don't put multiple statements on a single line unless you have something to hide," which goes on to give an example of how such statements can cause confusion:

         if (condition) do_this;
           do_something_everytime;

2.6 maintainer Andrew Morton [interview] quickly replied, "there are about 88 squillion of these in the kernel. I think it would be a mistake for me to start taking such patches, sorry." David Miller countered, "I disagree. Putting statements on the same line as the if statement hides bugs and makes the code harder to read." Andrew replied, "we all know that, but this means that we spend the next two years fielding an ongoing dribble of trivial patches which distract from real work."

A short discussion followed in which Andrew agreed, "well I suppose I could live with a few REALLY REALLY BIG patches to do this to lots of files, but if it's the old death-by-1000-cuts, I'm gonna call uncle this time." Jesper agreed to begin working on the large patches, to which Andrew repeated, "OK, a few 100k-400k patches would suit." A similar discussion was raised here.

speck-geostationary