Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 25 Aug 2003 10:46:16 +0200 | From | Pavel Machek <> | Subject | Re: Cpufreq for opteron |
| |
Hi!
> > > There's a *lot* of this in this driver. Does it really need > > that much > > > debugging info ? Additionally, the combination of dprintk, tprintk, > > > printk (KERN_DEBUG is really messy, and kind of defeats the point > > > of having these macros. If they're not going to be consistent, don't > > > use them at all. > > > > Yep, I do not like those ?printk's too. Anyway, I killed most #ifdef > > DEBUG, and converted it to BUG_ON(). That makes driver shorter and > > easier to read. Hopefully not much new hardware will be buggy. > > I am not really expecting to see a lot of buggy hardware. Hopefully ! > > I am, however, expecting to see BIOS problems. This code has been tested > internally on a few machines, and every single one of the had some form > or error in the BIOS. Even the AMD internal only development platforms > had problems Some of this stuff was defined kind of late, and went through > several revisions.
Okay, but hopefully machines being sold in retail will have bug-free BIOSes?
> There are many debug prints in the code, plus additional code that is > enabled when DEBUG/TRACE are defined. This is all there, based on the > experience of debugging these early machines in house.
You are welcome to keep the debugging version of your driver for debugging early machines; it is even possible that 2.4.X version distributed with SuSE is going to be "debugging" one. But I do not think Linus/Dave Jones is going to accept debugging version into mainline kernel.
[And I hope those BUG_ON()'s should be enough to do some debugging, too. You will not get a nice error message but ugly backtrack, but it should be enough].
> Without the debug/trace code there, I have to fall back to "please put > the machine in a box and mail it to me" instead of "email me the log > file".
Well, if your users will use SuSE 2.4 kernel, they will have logfile, anyway. By the time 2.6 is widely used, I *hope* bios problems are already fixed.
> I know the debug code is ugly ... but, I am expecting to need it. In the > next rev of the driver, when hardware is publicly for sale, we have some > degree of stability, etc ... then great. But, for now, releasing a driver > that has only been tested on prototype hardware ... and removing the > debug code. Ouch.
If we want the code to be in 2.6.X final, it is good to start pushing it _now_. And we can't reasonably expect linus to eat patch with _that_ much debugging.
Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |