[pvrusb2] Suppressing unneeded syslog debug output

[roger]

I sort of for saw this (that you preferred decent logging as I would do
the same).

If I were smart enough, all I had to do was:
modinfo pvrusb2 

(..must be because I'm really addicted to being slow lately.)


But setting the debug mask seems to not reduce much info logged to
syslog.

I'm not too concerned about this so please don't waste your time
responding to my ramblings here as I still have to spend time
calculating if the module is really accepting the options.  (I've
noticed some new features of module loading here.) 


On Fri, 2006-04-21 at 00:35 -0500, Mike Isely wrote:
> On Thu, 20 Apr 2006, roger wrote:
> 
> > Anything to suppress unneeded syslog debug output?
> >
> > Quite a few "/*---TRACE_*" comments and other output in syslog for those
> > of us who has older h/w where the driver works wonderfully?
> >
> > (I can make use of a debug use flag on gentoo to re-enable debug output
> > for users.  Just a thought.)
> >
> 
> That debug variable that you so surprisingly noticed earlier today 
> controls all of this.  It's a giant bit mask.  The definitions are in 
> pvrusb2-debug.h, and its default value is set in pvrusb2-main.c.  You can 
> control it at run-time either as a module load option or in real-time via 
> the standard sysfs means for accessing module option state for any module 
> (that ability is not unique to pvrusb2).  I believe I had written up a few 
> paragraphs about this on the main pvrusb2 web page.
> 
> The default value for the debug variable is basically set right now to 
> help with debugging.  I have pretty much everything turned on that 
> wouldn't otherwise impact performance (or overstuff the log) while 
> streaming is underway.  It can certainly be quieted down a lot, however 
> I've elected to leave all these things on by default because otherwise 
> right now every time somebody reports a problem and pastes their log my 
> very next answer is almost always going to be "please turn on the 
> following options, run the test again and send me the log again..."
> 
> Clearly most of that stuff is going to be shut off in the kernel, and I 
> think once things settle down more in V4L and the driver shows some 
> history of stability again, then these flags can be shut off.
> 
>    -Mike
> 
> 
--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61

Fri Apr 21 22:34:33 PDT 2006