All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: James Bottomley <James.Bottomley@suse.de>,
	"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	Jeff Garzik <jeff@garzik.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] SCSI queuecommand API change for 2.6.37-rc1
Date: Fri, 12 Nov 2010 17:42:06 -0800	[thread overview]
Message-ID: <AANLkTinj2BM2eGo2yyfzs=t+nu79WLW_bGYota9sDZwH@mail.gmail.com> (raw)
In-Reply-To: <1289606118.3015.539.camel@mulgrave.site>

On Fri, Nov 12, 2010 at 3:55 PM, James Bottomley
<James.Bottomley@suse.de> wrote:
>
> This patch set contains a single patch modifying the SCSI queuecommand
> host template API to go from being called with the host lock held to
> being called locklessly.  The transformation is a directly equivalent
> one (i.e. the locking is simply pushed into each HBA) but will form the
> basis for optimising locking in the driver patch for the next merge
> window.

Ok, so we talked about this patch at the KS, but I never saw it.

And now seeing it, I do detest it.

Why? Because if some driver gets missed for any reason (notably if
it's currently out of tree, and gets merged later), afaik there will
be ABSOLUTELY ZERO compiler warnings or anything about it, because you
kept the "queuecommand" function exactly the same. Whether it's a
locked or non-locked one, it always is of type

    int func(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *));

so there is no inherent type safety. Nothing will ever notice. Not the
compiler, and probably not the user either, since a missed lock with
probably work in many cases.

So it's a flag-day change, but it's a flag-day change which makes it
_really_ easy to miss the fact that a big change had actually
happened.

And the sad thing is that this could _trivially_ have been fixed while
actually making the patch no bigger. Make the new function look like

   int func(struct Scsi_Host *shost, struct scsi_cmnd *cmd, void
(*done)(struct scsi_cmnd *));

instead, and that would have made the "DEF_SCSI_QCMD()" macro simpler
and cleaner, it would likely make the code better (since the caller
really already always has the 'shost' right there, so looking it up
agan in cmd->device->shost is just extra work), _and_ it would mean
that if some driver didn't get converted, the compiler would
automatically have noticed.

And the patch would look 100% the same, except for these three small
one-liner changes:
 - the additional one-liner change to the 'queuecommand' function
pointer description itself
 - the one-liner change to the actual call-site (which would now not
just drop the lock, it would pass in the extra argument)
 - DEF_SCSI_QCMD() would drop the "struct Scsi_Host *shost = .." line,
and instead just take the new argument

It wouldn't change the patch wrt any of the low-level drivers at all.
But it would add so much inherent safety against mistakes.

It would _also_ make it much clearer when each driver is then starting
to remove that use of the wrapper function. When you remove the
wrapper function, you'd probably remove the "_lck" thing at the end of
the name, but you'd also change the prototype. It would be a very
clear visual clue whether this was a properly converted driver, or
whether this was a driver that had never seen the whole locking change
at all.

So please: when you change the semantics of a function, just change
the function prototype (or function name) at the same time. Especially
when it comes to a driver interface, so that the drivers don't get
taken by surprise.

Type safety and automatic compiler warnings really are our friends.
Especially when the patch was presumably mostly auto-generated, and
maybe the script missed something, and missing some conversion has
such subtle effects.

                        Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: James Bottomley <James.Bottomley@suse.de>,
	"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	Jeff Garzik <jeff@garzik.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] SCSI queuecommand API change for 2.6.37-rc1
Date: Fri, 12 Nov 2010 17:42:06 -0800	[thread overview]
Message-ID: <AANLkTinj2BM2eGo2yyfzs=t+nu79WLW_bGYota9sDZwH@mail.gmail.com> (raw)
In-Reply-To: <1289606118.3015.539.camel@mulgrave.site>

On Fri, Nov 12, 2010 at 3:55 PM, James Bottomley
<James.Bottomley@suse.de> wrote:
>
> This patch set contains a single patch modifying the SCSI queuecommand
> host template API to go from being called with the host lock held to
> being called locklessly.  The transformation is a directly equivalent
> one (i.e. the locking is simply pushed into each HBA) but will form the
> basis for optimising locking in the driver patch for the next merge
> window.

Ok, so we talked about this patch at the KS, but I never saw it.

And now seeing it, I do detest it.

Why? Because if some driver gets missed for any reason (notably if
it's currently out of tree, and gets merged later), afaik there will
be ABSOLUTELY ZERO compiler warnings or anything about it, because you
kept the "queuecommand" function exactly the same. Whether it's a
locked or non-locked one, it always is of type

    int func(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *));

so there is no inherent type safety. Nothing will ever notice. Not the
compiler, and probably not the user either, since a missed lock with
probably work in many cases.

So it's a flag-day change, but it's a flag-day change which makes it
_really_ easy to miss the fact that a big change had actually
happened.

And the sad thing is that this could _trivially_ have been fixed while
actually making the patch no bigger. Make the new function look like

   int func(struct Scsi_Host *shost, struct scsi_cmnd *cmd, void
(*done)(struct scsi_cmnd *));

instead, and that would have made the "DEF_SCSI_QCMD()" macro simpler
and cleaner, it would likely make the code better (since the caller
really already always has the 'shost' right there, so looking it up
agan in cmd->device->shost is just extra work), _and_ it would mean
that if some driver didn't get converted, the compiler would
automatically have noticed.

And the patch would look 100% the same, except for these three small
one-liner changes:
 - the additional one-liner change to the 'queuecommand' function
pointer description itself
 - the one-liner change to the actual call-site (which would now not
just drop the lock, it would pass in the extra argument)
 - DEF_SCSI_QCMD() would drop the "struct Scsi_Host *shost = .." line,
and instead just take the new argument

It wouldn't change the patch wrt any of the low-level drivers at all.
But it would add so much inherent safety against mistakes.

It would _also_ make it much clearer when each driver is then starting
to remove that use of the wrapper function. When you remove the
wrapper function, you'd probably remove the "_lck" thing at the end of
the name, but you'd also change the prototype. It would be a very
clear visual clue whether this was a properly converted driver, or
whether this was a driver that had never seen the whole locking change
at all.

So please: when you change the semantics of a function, just change
the function prototype (or function name) at the same time. Especially
when it comes to a driver interface, so that the drivers don't get
taken by surprise.

Type safety and automatic compiler warnings really are our friends.
Especially when the patch was presumably mostly auto-generated, and
maybe the script missed something, and missing some conversion has
such subtle effects.

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2010-11-13  1:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-12 23:55 [GIT PULL] SCSI queuecommand API change for 2.6.37-rc1 James Bottomley
2010-11-13  0:38 ` Nicholas A. Bellinger
2010-11-13  1:42 ` Linus Torvalds [this message]
2010-11-13  1:42   ` Linus Torvalds
2010-11-13  2:03   ` Jeff Garzik
2010-11-13  2:09     ` Jeff Garzik
2010-11-13  2:30       ` Linus Torvalds
2010-11-13  4:28   ` Matthew Wilcox
2010-11-13  4:42     ` Linus Torvalds
2010-11-13  5:26       ` Jeff Garzik
2010-11-13  6:01       ` James Bottomley
2010-11-13  6:07         ` Jeff Garzik
2010-11-13  7:18           ` Nicholas A. Bellinger
2010-11-16  6:57         ` Jeff Garzik
2010-11-16  7:08           ` Jeff Garzik
2010-11-13  5:16   ` [PATCH v4] SCSI host lock push-down Jeff Garzik
2010-11-13  6:01     ` Jeff Garzik
2010-11-16  7:10     ` [PATCH v5] " Jeff Garzik
2010-11-16  7:31       ` Jeff Garzik
2010-11-16 17:25       ` Linus Torvalds
2010-11-16 17:36         ` James Bottomley
2010-11-16 21:30           ` Linus Torvalds
2010-11-16 21:32             ` James Bottomley
2010-11-16 21:26         ` Jeff Garzik

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='AANLkTinj2BM2eGo2yyfzs=t+nu79WLW_bGYota9sDZwH@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=James.Bottomley@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nab@linux-iscsi.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 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.