All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: David Miller <davem@davemloft.net>
Cc: sfr@canb.auug.org.au, linux-next@vger.kernel.org, rmk@arm.linux.org.uk
Subject: Re: linux-next: net tree build failure
Date: Tue, 09 Dec 2008 10:12:53 +0100	[thread overview]
Message-ID: <1228813973.19553.2.camel@violet.holtmann.net> (raw)
In-Reply-To: <20081209.010503.36680697.davem@davemloft.net>

Hi Dave,

> > On Tue, 09 Dec 2008 00:04:23 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> > > diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> > > index ad00cbf..ffaa6b0 100644
> > > --- a/net/bluetooth/rfcomm/sock.c
> > > +++ b/net/bluetooth/rfcomm/sock.c
> > > @@ -792,7 +792,7 @@ static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned lon
> > >  #endif
> > >  	int err;
> > >  
> > > -	BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
> > > +	BT_DBG("sk %p cmd %x arg %lx", sock, cmd, arg);
> > 
> > I am not sure this is correct as there is a "sk" defined just above here
> > but surrounded by
> > 
> > #if defined(CONFIG_BT_RFCOMM_TTY) || defined(CONFIG_BT_RFCOMM_DEBUG)
> 
> Hmmm...
> 
> BT_DBG is unconditionally defined these days.  And it evaluates to
> pr_debug() which is conditional on other "DEBUG" or
> "DYNAMIC_PRINTK_DEBUG".
> 
> This looks like a job for either __maybe_unused since I can't see
> a clean way to keep this issue inside of the BT_DBG() macro
> definition since it's varargs.
> 
> So, I've gone with this for now:
> 
> bluetooth: Fix unused var warning properly in rfcomm_sock_ioctl().
> 
> As Stephen Rothwell points out, we don't want 'sock' here but
> rather we really do want 'sk'.
> 
> This local var is protected by all sorts of bluetooth debugging
> kconfig vars, but BT_DBG() is just a straight pr_debug() call
> which is unconditional.
> 
> pr_debug() evaluates it's args only if either DEBUG or
> CONFIG_DYNAMIC_PRINTK_DEBUG is defined.
> 
> Solving this inside of the BT_DBG() macro is non-trivial since
> it's varargs.  And these ifdefs are ugly.
> 
> So, just mark this 'sk' thing __maybe_unused and kill the ifdefs.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  net/bluetooth/rfcomm/sock.c |    6 ++----
>  1 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index ffaa6b0..d3fc6fc 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -787,12 +787,10 @@ static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, c
>  
>  static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
>  {
> -#if defined(CONFIG_BT_RFCOMM_TTY) || defined(CONFIG_BT_RFCOMM_DEBUG)
> -	struct sock *sk = sock->sk;
> -#endif
> +	struct sock *sk __maybe_unused = sock->sk;
>  	int err;
>  
> -	BT_DBG("sk %p cmd %x arg %lx", sock, cmd, arg);
> +	BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
>  
>  	err = bt_sock_ioctl(sock, cmd, arg);

Acked-by: Marcel Holtmann <marcel@holtmann.org>

This looks actually pretty much how it should be. The ifdefs got added
because someone actually saw a compiler warning of an unused variable
when disabling CONFIG_BT_RFCOMM_TTY. So in 99% of the case this is
enabled, because otherwise it makes no sense, but for some really
embedded stuff where no TTYs are required they can disable it and shrink
their kernel a lot.

Regards

Marcel

  reply	other threads:[~2008-12-09  9:13 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-09  6:29 linux-next: net tree build failure Stephen Rothwell
2008-12-09  8:04 ` David Miller
2008-12-09  8:54   ` Stephen Rothwell
2008-12-09  9:05     ` David Miller
2008-12-09  9:12       ` Marcel Holtmann [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-01-27  2:18 Stephen Rothwell
2010-01-27  4:49 ` David Miller
2010-01-11  7:42 Stephen Rothwell
2010-01-11  7:42 ` Stephen Rothwell
2010-01-11  8:02 ` David Miller
2010-01-11  8:16   ` Joe Perches
2010-01-11  8:44     ` David Miller
2010-01-11  8:49       ` Stephen Rothwell
2010-01-11 11:16     ` Maciej W. Rozycki
2009-11-18  5:51 Stephen Rothwell
2009-11-18  7:05 ` David Miller
2009-11-19 10:51   ` Shreyas Bhatewara
2009-11-14  6:50 Stephen Rothwell
2009-11-14  6:50 ` Stephen Rothwell
2009-11-14 13:18 ` Arnaldo Carvalho de Melo
2009-11-09  2:21 Stephen Rothwell
2009-11-09  2:21 ` Stephen Rothwell
2009-11-09  4:41 ` David Miller
2009-10-13  4:33 Stephen Rothwell
2009-10-13  5:14 ` Michael Chan
2009-10-13  6:20   ` David Miller
2009-10-13  6:19 ` David Miller
2009-06-17  6:31 Stephen Rothwell
2009-06-17  8:36 ` David Miller
2009-06-17 13:10   ` Stephen Rothwell
     [not found] <20090521001928.4bf71911.sfr@canb.auug.org.au>
2009-05-20 14:53 ` Eric W. Biederman
2009-05-20 19:44   ` David Miller
2009-04-24  7:01 Stephen Rothwell
2009-04-24 11:53 ` David Miller
2009-04-24 11:57   ` Stephen Rothwell
2009-04-22  0:29 Stephen Rothwell
2009-04-22  0:37 ` Alexander Beregalov
2009-04-22  1:12   ` David Miller
2009-04-20  1:26 Stephen Rothwell
2009-04-20  1:36 ` Alexander Beregalov
2009-04-20  1:43   ` David Miller
2009-04-20  1:50     ` Stephen Rothwell
2009-03-19  4:46 Stephen Rothwell
2009-03-19  5:40 ` David Miller
2009-04-01 19:58   ` Ingo Molnar
2009-04-01 21:22     ` David Miller
2009-03-30  1:15 ` Stephen Rothwell
2009-03-30  1:50   ` Stephen Rothwell
2009-03-02  7:05 Stephen Rothwell
2009-03-02  9:49 ` David Miller
2009-03-02 16:38   ` Andy Grover
2009-03-03  1:55   ` Stephen Rothwell
2009-03-03  3:22     ` Andy Grover
2009-01-26  2:53 Stephen Rothwell
2009-01-26  4:46 ` David Miller
2009-01-26  5:15   ` Stephen Rothwell
2009-01-26  5:17     ` David Miller
2009-01-26  8:31       ` Stephen Rothwell
2009-01-26 19:40         ` David Miller
2009-01-23  7:28 Stephen Rothwell
2009-01-23  7:56 ` David Miller
2009-01-23  8:01   ` Stephen Rothwell
2009-01-23  8:13     ` David Miller
2009-01-23 10:21       ` Stephen Rothwell
2009-01-23 10:39         ` Stephen Rothwell
2009-01-23 10:50           ` Stephen Rothwell
2009-01-24  6:27             ` David Miller
2008-11-28  3:46 Stephen Rothwell
2008-11-28  7:07 ` David Miller
2008-11-26  7:15 Stephen Rothwell
2008-11-26  7:51 ` Herbert Xu
2008-11-26  8:45 ` David Miller
2008-11-26  9:40   ` Stephen Rothwell
2008-11-24  2:43 Stephen Rothwell
2008-11-24  3:56 ` David Miller
2008-11-24  4:03   ` David Miller
2008-11-24  4:25   ` Stephen Rothwell
2008-11-24  4:28     ` David Miller
2008-11-24  4:49       ` Stephen Rothwell
2008-11-24  5:04         ` David Miller
2008-11-24  5:20           ` Stephen Rothwell
2008-11-24  5:22             ` Stephen Rothwell
2008-11-24  5:23             ` David Miller
2008-11-24  5:29               ` David Miller
2008-11-24  5:45                 ` Stephen Rothwell
2008-11-24  5:38               ` Stephen Rothwell
2008-11-24 21:00                 ` Sam Ravnborg
2008-11-24 21:52                   ` Stephen Hemminger
2008-11-24 22:12                     ` Sam Ravnborg
2008-11-25  8:42                       ` Stephen Rothwell
2008-11-25  9:01                         ` Sam Ravnborg
2008-11-21  2:44 Stephen Rothwell
2008-11-21  4:02 ` Stephen Hemminger
2008-11-21  4:13   ` David Miller
2008-11-20  2:58 Stephen Rothwell
2008-11-20  2:30 Stephen Rothwell
2008-12-29  6:45 ` Stephen Rothwell
2008-09-13  5:03 Stephen Rothwell
2008-09-13  6:24 ` David Miller
2008-09-13  9:42   ` Stephen Rothwell
2008-09-15  0:54 ` Simon Horman

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=1228813973.19553.2.camel@violet.holtmann.net \
    --to=marcel@holtmann.org \
    --cc=davem@davemloft.net \
    --cc=linux-next@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=sfr@canb.auug.org.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.