All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Christoph Hellwig <hch@lst.de>,
	jejb@SteelEye.com, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] fix up request buffer reference in various scsi drivers
Date: Thu, 08 Jun 2006 10:17:01 -0400	[thread overview]
Message-ID: <4488315D.9040001@garzik.org> (raw)
In-Reply-To: <1149774847.3436.11.camel@mulgrave.il.steeleye.com>

James Bottomley wrote:
> On Thu, 2006-06-08 at 09:26 -0400, Jeff Garzik wrote:
>> James Bottomley wrote:
>>> On Thu, 2006-06-08 at 07:37 -0400, Jeff Garzik wrote:
>>>> False statement, for libata.
>>> Could you amplify this statement, please ... I looked through the head
>>> of libata-dev and it seems that these are still the only two bufflen
>>> uses, which still do look obviously wrong ... I don't see where the
>>> problem in libata with this is?
>> Christoph's false statement is:  "Using the buffer and bufflen fields 
>> means they do very broken things in error handling."
>>
>> libata does not do "very broken things in error handling."
> 
> OK ... let me explain what we're doing a bit.  One of the things that
> has been going on for quite a while is that Intel (Ken Chen) has
> analyses showing that allocation clearing and freeing of the scsi_cmnd
> structure is a drag on the fast path.  This is part of the drive to slim
> it down (i.e. get rid of a lot of the fields that are only used in eh).

OK.

Since libata does EH differently than all other SCSI drivers, it 
certainly makes sense to CC the appropriate maintainers.


>>>> Please CC the author (me) or linux-ide, at least, when you touch
>>>> libata.
>>> The tradition is that for infrastructure changes like this, particularly
>>> ones that are trivial, as this appears to be, you simply copy the scsi
>>> list and don't have to sweep up the individual maintainers of each
>>> driver.
>> This is apparently an EH-related patch, and libata uses SCSI EH very 
>> differently from all other drivers.  In this case, Christoph's "very 
>> broken" justification is clearly inaccurate, and thus a CC is obviously 
>> warranted.
>>
>> Also, I remind people constantly of this, so I'm sure you and Christoph 
>> have heard the request before.
>>
>> 	Jeff, the one who forwards to linux-scsi when others forget
> 
> I appreciate that for changes you want to make to SCSI.  However, this
> particular patch touches seventeen separately maintained pieces of code
> within the SCSI subsystem, only one of which is libata.  I'm really
> reluctant to change the policy in this regard ... it's a policy we
> copied from lkml ... that for sweeping infrastructure changes we only
> send it to the list and don't have to work out who all the maintainers
> are.

If the submittor is under the impression that libata's error handling is 
"very broken", I would appreciate a clarification.  Otherwise, one must 
assume that the submittor should have CC'd linux-ide and relevant 
maintainers, because they do not understand the code they are patching.

What _precisely_ is broken, given that libata does all its own error 
handling, and ignores scsi_unjam_host() ?

	Jeff



  reply	other threads:[~2006-06-08 14:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-03 11:21 [PATCH] fix up request buffer reference in various scsi drivers Christoph Hellwig
2006-06-08 11:37 ` Jeff Garzik
2006-06-08 13:01   ` Matthew Wilcox
2006-06-08 13:06   ` James Bottomley
2006-06-08 13:26     ` Jeff Garzik
2006-06-08 13:54       ` James Bottomley
2006-06-08 14:17         ` Jeff Garzik [this message]
2006-06-08 14:35           ` James Bottomley
2006-06-08 14:44             ` Jeff Garzik
2006-06-08 17:40 ` James Bottomley
2006-06-08 17:46   ` Christoph Hellwig

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=4488315D.9040001@garzik.org \
    --to=jeff@garzik.org \
    --cc=James.Bottomley@SteelEye.com \
    --cc=hch@lst.de \
    --cc=jejb@SteelEye.com \
    --cc=linux-scsi@vger.kernel.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.