On Tue, 2011-01-25 at 00:56 +0100, Stefan Richter wrote:
> On Jan 24 Nicholas A. Bellinger wrote:
> > On Mon, 2011-01-24 at 15:51 -0600, James Bottomley wrote:
> > > On Mon, 2011-01-24 at 13:33 -0800, Nicholas A. Bellinger wrote:
> > > > On Mon, 2011-01-24 at 14:56 -0600, James Bottomley wrote:
> > > > > On Mon, 2011-01-24 at 12:37 -0800, Nicholas A. Bellinger wrote:
> > > > > > -#define TASK_CMD(task) ((struct se_cmd *)task->task_se_cmd)
> > > > > > -#define TASK_DEV(task) ((struct se_device *)task->se_dev)
> > > > > > +#define TASK_CMD(task) ((task)->task_se_cmd)
> > > > > > +#define TASK_DEV(task) ((task)->se_dev)
> > > > >
> > > > > If sparse is objecting to things like this then sparse needs fixing:
> > > > > It's decreasing typesafety. the things being cast are void * ... they'd
> > > > > be depositable into any pointer whatsoever without the cast. With the
> > > > > cast in the #define, we pick up pointer mismatches (as we should).
> > > > > Without it, we don't. As long as the define is always a specific type,
> > > > > it *should* cast to it.
> > > > >
> > > >
> > > > Hmmm, good point.. In that case I will go ahead and drop this part of
> > > > the patch.
> > >
> > > Actually, I misspoke on this. They're not void *; they're defined as
> > > struct pointers ... so the cast is actually a spurious double cast. As
> > > long as the rest are, I'm fine with this.
> > >
> >
> > Committed as seperate commit b58b76c -> lio-core-2.6.git/linus-38-rc2,
> > and picked into the mainline queue @ scsi-post-merge-2.6.git/for-jejb.
>
> Why do you provide macros for a simple structure member dereference?
>
> And if you *really* need these helpers, why not
>
> static inline struct se_cmd *cmd_of(struct se_task *task)
> {
> return task->task_se_cmd;
> }
>
> (But then, I see no reason at all not to write it as task->task_se_cmd at
> the user sites.)
Most of these accessor macros originally came from the usage of more
than a single pointer deference. These days only DEV_ATTRIB and
DEV_T10_WWN still deference multiple pointers, so it's really just a
matter of style in modern v4.0 code.
So my perference would be against using inlined cmd_of() callers, and
just access things directly. Btw at this point this type of cleanup
would be considered for-39 material.
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
