Re: Cpufreq for opteron

[Pavel Machek <pavel@suse.cz>]

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?]