[alsa-devel] [PATCH] ALSA: get rid of CONFIG_SND_VERBOSE_PRINTK
tiwai at suse.de
Fri Jun 7 07:57:39 CEST 2013
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.
More information about the Alsa-devel