linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	Jens Axboe <jens.axboe@oracle.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Sebastian Siewior <ide+bug@ml.breakpoint.cc>,
	Tejun Heo <htejun@gmail.com>,
	Sergei Shtylyov <sshtylyov@ru.mvista.com>,
	linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: Subject: [PATCH 1/3] Let scsi_cmnd->cmnd use request->cmd	buffer
Date: Tue, 12 Feb 2008 20:10:51 +0200	[thread overview]
Message-ID: <47B1E12B.6060900@panasas.com> (raw)
In-Reply-To: <20080212174522.GA26316@infradead.org>

On Tue, Feb 12 2008 at 19:45 +0200, Christoph Hellwig <hch@infradead.org> wrote:
> On Sun, Feb 10, 2008 at 09:05:17PM +0200, Boaz Harrosh wrote:
>> - Lots of drivers still use MAX_COMMAND_SIZE. So I have left
>>   that #define but equate it to BLK_MAX_CDB. The way I see it
>>   and is reflected in the patch below is.
>>   MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB
>>                      as per the SCSI standard and is not related
>>                      to the implementation.
>>   BLK_MAX_CDB.     - The allocated space at the request level
>>
>> (*)fixed-length here means commands that their size can be determined
>>    by their opcode and the CDB does not carry a length specifier, like
>>    the VARIABLE_LENGTH_CMD(0x7f) command. This is actually not exactly
>>    true and the SCSI standard also defines extended commands and
>>    vendor specific commands that can be bigger than 16 bytes. The kernel
>>    will support these using the same infrastructure used for VARLEN CDB's.
>>    So in effect MAX_COMMAND_SIZE means the maximum size command
>>    scsi-ml supports without specifying a cmd_len by ULD's
> 
> A comment like this should be near the declaration of MAX_COMMAND_SIZE
> 
>> +#define MAX_COMMAND_SIZE 16
>> +#if (MAX_COMMAND_SIZE > BLK_MAX_CDB)
>> +#	error MAX_COMMAND_SIZE can not be smaller than BLK_MAX_CDB
>> +#endif
> 
> No tabs between the # and the rest of the cpp command, please.  Either
> nothing or a single space as indentation instead.
> 
> Except for those two small nitpicks this looks very good to me.  Nice
> memory saving aswel.
Agree with both comments. Thanks for the review, will fix in the next
submission.

Boaz

  reply	other threads:[~2008-02-12 18:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-09 19:32 Current git --> kaboom [bisect] seems IDE related Sebastian Siewior
2008-02-09 20:28 ` Bartlomiej Zolnierkiewicz
2008-02-09 21:22   ` Sebastian Siewior
2008-02-09 23:06     ` Bartlomiej Zolnierkiewicz
2008-02-10  5:26       ` Christoph Hellwig
2008-02-10 13:38         ` Bartlomiej Zolnierkiewicz
2008-02-10 14:19           ` James Bottomley
2008-02-10 18:32             ` Bartlomiej Zolnierkiewicz
2008-02-10 19:51               ` Sebastian Siewior
2008-02-10 23:16                 ` Bartlomiej Zolnierkiewicz
2008-02-11 16:30               ` Sergei Shtylyov
2008-02-11 19:41                 ` Bartlomiej Zolnierkiewicz
2008-02-10 14:43           ` Christoph Hellwig
2008-02-10 15:07             ` Boaz Harrosh
2008-02-10 18:59               ` [PATCHSET 0/3] varlen extended and vendor-specific cdbs Boaz Harrosh
2008-02-10 19:05                 ` Subject: [PATCH 1/3] Let scsi_cmnd->cmnd use request->cmd buffer Boaz Harrosh
2008-02-12 17:45                   ` Christoph Hellwig
2008-02-12 18:10                     ` Boaz Harrosh [this message]
2008-02-12 19:41                   ` James Bottomley
2008-02-13  9:24                     ` Boaz Harrosh
2008-02-10 19:09                 ` [PATCH 2/3] block layer varlen-cdb Boaz Harrosh
2008-02-12 17:48                   ` Christoph Hellwig
2008-02-12 17:54                     ` Boaz Harrosh
2008-02-12 18:07                       ` Boaz Harrosh
2008-02-10 19:12                 ` [PATCH 3/3] scsi: varlen extended and vendor-specific cdbs Boaz Harrosh
2008-02-12 17:51                   ` Christoph Hellwig
2008-02-12 18:17                     ` Boaz Harrosh

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=47B1E12B.6060900@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=bzolnier@gmail.com \
    --cc=hch@infradead.org \
    --cc=htejun@gmail.com \
    --cc=ide+bug@ml.breakpoint.cc \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sshtylyov@ru.mvista.com \
    /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).