Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Takashi Iwai <tiwai@suse.de>, alsa-devel@alsa-project.org
Subject: Re: [PATCH] ALSA: get rid of CONFIG_SND_VERBOSE_PRINTK
Date: Thu, 06 Jun 2013 14:50:32 -0700	[thread overview]
Message-ID: <1370555432.2209.55.camel@joe-AO722> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1306061654270.878-100000@iolanthe.rowland.org>

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?

  reply	other threads:[~2013-06-06 21:50 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-03 20:18 [PATCH] ALSA: get rid of CONFIG_SND_VERBOSE_PRINTK Alan Stern
2013-06-03 20:24 ` Joe Perches
2013-06-03 20:40   ` Alan Stern
2013-06-03 20:49     ` Joe Perches
2013-06-04  9:13 ` Takashi Iwai
2013-06-04 14:49   ` Alan Stern
2013-06-04 15:03     ` Takashi Iwai
2013-06-04 17:20       ` [PATCH 1/2] ALSA: convert "snd_printk(KERN_INFO" to "pr_info(" Alan Stern
2013-06-05  5:52         ` Takashi Iwai
2013-06-05  6:07           ` Joe Perches
2013-06-05  6:16             ` Takashi Iwai
2013-06-06 20:54           ` Alan Stern
2013-06-07  5:41             ` Takashi Iwai
2013-06-07 15:51               ` Alan Stern
2013-06-04 17:20       ` [PATCH 2/2 v.2] ALSA: get rid of CONFIG_SND_VERBOSE_PRINTK Alan Stern
2013-06-04 19:32       ` [PATCH] " Alan Stern
2013-06-04 19:45         ` Joe Perches
2013-06-04 20:54           ` Alan Stern
2013-06-04 21:19             ` Joe Perches
2013-06-06 20:42               ` Alan Stern
2013-06-06 20:59                 ` Joe Perches
2013-06-07 14:40                   ` Alan Stern
2013-06-07 16:10                     ` Joe Perches
2013-06-05  6:04             ` Takashi Iwai
2013-06-05  6:15               ` Joe Perches
2013-06-05  6:32                 ` Takashi Iwai
2013-06-05  6:52                   ` Joe Perches
2013-06-05  6:54                     ` Takashi Iwai
2013-06-05  7:07                       ` Joe Perches
2013-06-05  7:22                         ` Takashi Iwai
2013-06-05  7:34                           ` Joe Perches
2013-06-05  7:47                             ` CONFIG_SND_DEBUG (was: Re: [alsa-devel] [PATCH] ALSA: get rid of CONFIG_SND_VERBOSE_PRINTK) David Henningsson
2013-06-05  8:46                               ` CONFIG_SND_DEBUG (was: " Takashi Iwai
2013-06-05 10:53                               ` CONFIG_SND_DEBUG (was: Re: [alsa-devel] " Andy Whitcroft
2013-06-05 11:38                                 ` CONFIG_SND_DEBUG David Henningsson
2013-06-05 11:43                                   ` CONFIG_SND_DEBUG Takashi Iwai
2013-06-05 14:11                                     ` CONFIG_SND_DEBUG Alan Stern
2013-06-05 14:28                                       ` CONFIG_SND_DEBUG Takashi Iwai
2013-06-05 14:47                                         ` CONFIG_SND_DEBUG Alan Stern
2013-06-06 21:28               ` [PATCH] ALSA: get rid of CONFIG_SND_VERBOSE_PRINTK Alan Stern
2013-06-06 21:50                 ` Joe Perches [this message]
2013-06-07  5:57                   ` Takashi Iwai
2013-06-07 15:34                     ` Alan Stern
2013-06-07  5:53                 ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1370555432.2209.55.camel@joe-AO722 \
    --to=joe@perches.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox