From: James Bottomley <James.Bottomley@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Andrew Morton <akpm@linux-foundation.org>,
linux-scsi@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] first round of SCSI updates for the 2.6.36 merge window
Date: Thu, 05 Aug 2010 19:32:48 -0500 [thread overview]
Message-ID: <1281054768.22157.2.camel@mulgrave.site> (raw)
In-Reply-To: <AANLkTintTMXirWF+Y-CwK4dn8Mqk8=ba9_+yjX9P837V@mail.gmail.com>
On Wed, 2010-08-04 at 15:51 -0700, Linus Torvalds wrote:
> On Tue, Aug 3, 2010 at 9:13 PM, James Bottomley <James.Bottomley@suse.de> wrote:
> >
> > Alan Stern (3):
> > sd: add support for runtime PM
> > implement runtime Power Management
> > convert to the new PM framework
>
> Guys, these kind of crazy games really aren't appropriate:
>
> +/* scsi_pm.c */
> +#ifdef CONFIG_PM_OPS
> +extern const struct dev_pm_ops scsi_bus_pm_ops;
> +#else
> +#define scsi_bus_pm_ops (*NULL)
> +#endif
>
> that's just crazy. Yes, I see how it's then used (address-of operator
> turns it back into NULL), but the compiler warns about it
> ("drivers/scsi/scsi_sysfs.c:384: warning: dereferencing ‘void *’
> pointer") and I think the compiler is 100% correct about warning about
> it.
Sigh ... I did actually check this because I thought the compiler would
warn. Apparently it only warns on certain versions.
> It's not just the (*NULL) games, btw. The above can cause confusion.
> It's ugly not just because it causes the compiler to warn, but because
> you use a very subtle and non-standard way of using #define's, so that
> when you look at the source code where this is used, it's not at all
> obvious what is going on. The code looks like
>
> .pm = &scsi_bus_pm_ops,
>
> and dammit, it would be rather understandable if some _human_ that
> reads that is also confused and thinks that the above means that the
> .pm pointer can never be NULL. The address-of would certainly throw
> me, and not necessarily at all make me grep for "could that possibly
> be some crazy way to say NULL".
>
> And there is absolutely no reason to play games like that. It would
> have been entirely understandable if you just put the #ifdef in the C
> code itself, or if you used a #define that just said
>
> #ifdef CONFIG_PM_OPS
> #define SCSI_BUS_PM_OPS &scsi_bus_pm_ops
> #else
> #define SCSI_BUS_PM_OPS NULL
> #endif
>
> and I think it would be less confusing, and it wouldn't upset the compiler.
>
> Yes, yes, I realize that we do these kinds of things for function
> pointers all the time, so I do understand where the pattern comes
> from. At the same time, I rather think that function pointers are a
> bit different, and they don't have the whole address-of problem.
>
> I guess I should be happy that you didn't use some linker tricks to
> make "&scsi_bus_pm_ops" turn into NULL at link time. That could be
> done too, and would have been even more subtly confusing.
Agreed. Alan already sent a patch to fix it. I'll add it for the final
SCSI patch set.
James
prev parent reply other threads:[~2010-08-06 0:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-04 4:13 James Bottomley
2010-08-04 22:51 ` Linus Torvalds
2010-08-05 17:09 ` Alan Stern
2010-08-05 17:17 ` [PATCH] SCSI: remove fake "address-of" expression Alan Stern
2010-08-06 0:32 ` James Bottomley [this message]
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=1281054768.22157.2.camel@mulgrave.site \
--to=james.bottomley@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=torvalds@linux-foundation.org \
/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
all inboxes | Powered by JetHome®