Re: [PATCH] ALSA: get rid of CONFIG_SND_VERBOSE_PRINTK

[Takashi Iwai <tiwai@suse.de>]

At Thu, 06 Jun 2013 14:50:32 -0700,
Joe Perches wrote:
> 
> On Thu, 2013-06-06 at 17:28 -0400, Alan Stern wrote:
> > The important point is that these files are _drivers_; what matters at
> > runtime is the device name.  On systems with more than one sound card
> > of the same type, the device name is vital, but even on others it still
> > helps a lot.
> > 
> > What I want to do is make the messages include the device and driver
> > names.  Basically this means calling dev_info() and friends instead of
> > "snd_printk(KERN_INFO" or pr_info().  As part of the fallout from this
> > change, it should no longer be necessary to print the filename or
> > module name.  If a driver contains multiple identical messages, they
> > can be made non-identical (assuming it really matters; messages like
> > "can't allocate memory" usually don't need to be pinned down exactly).  
> > Line numbers are even less useful because they can change from one
> > kernel version to the next.
> > 
> > I can't convert the entire sound subsystem at once -- it's way too big.  
> > But I can at least do the sound/usb subsystem.  If this means that two
> > different logging APIs are used by different sets of sound drivers, so
> > be it.
> > 
> > In theory, this would be more or less independent of the patches posted 
> > so far.  In fact, when taken to its logical extreme, _all_ the messages 
> > would use dev_*() or some variant.  There wouldn't be any snd_printk(), 
> > snd_printd(), pr_info(), ... messages left to worry about.
> > 
> > I don't expect that to happen any time soon.  Still, I think it makes
> > more sense to concentrate on converting the messages below sound/usb
> > rather than fiddling around with the existing API, which is inadequate
> > anyway since it doesn't include the device.
> 
> I agree with that.
> 
> It'd be pretty easy to take that large patch that did
> snd_printk(fmt, ...) -> snd_dbg(1, fmt, ...) and
> convert it to snd_card_dbg(card *, fmt, ...)
> whenever a struct snd_card * was available.
> 
> snd_card_dbg() would be either a macro or a function
> to deference the snd_card * dev and maybe emit
> "struct snd_card.shortname" with it too.
> 
> Want to start with that?

As discussed earlier, the snd_card instance isn't always appropriate
for retrieving the device pointer.  It might help some driver codes,
but not always.

In the case of sound/usb/*, most of codes rather handle directly the
USB device pointer (mostly struct usb_interface), thus it's more
natural to use it directly, IMO.


thanks,

Takashi