All of lore.kernel.org
 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: 28+ 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
2008-03-25 15:57               ` [PATCHSET 0/3] Is it time for " 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 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.