linux-next.vger.kernel.org archive mirror
 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: 98+ 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  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 13:18 ` Arnaldo Carvalho de Melo
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).