* Support for CDB length > 16
@ 2003-11-18 8:49 Liran Schour
2003-11-18 9:33 ` Douglas Gilbert
2003-11-18 11:31 ` Christoph Hellwig
0 siblings, 2 replies; 9+ messages in thread
From: Liran Schour @ 2003-11-18 8:49 UTC (permalink / raw)
To: linux-scsi
Hi all,
I need a support from the Linux SCSI subsystem for CDB length > 16 byte.
Is it possible to do that without recompiling the kernel with a new
MAX_COMMAND_SIZE definition. I assume that I can find an iscsi driver that
is able to support CDB > 16 byte.
Thanks,
- Liran
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Support for CDB length > 16
2003-11-18 8:49 Support for CDB length > 16 Liran Schour
@ 2003-11-18 9:33 ` Douglas Gilbert
2003-11-18 11:15 ` Liran Schour
2003-11-18 11:21 ` Andre Hedrick
2003-11-18 11:31 ` Christoph Hellwig
1 sibling, 2 replies; 9+ messages in thread
From: Douglas Gilbert @ 2003-11-18 9:33 UTC (permalink / raw)
To: Liran Schour; +Cc: linux-scsi
Liran Schour wrote:
>
> I need a support from the Linux SCSI subsystem for CDB length > 16 byte.
> Is it possible to do that without recompiling the kernel with a new
> MAX_COMMAND_SIZE definition.
It is hard to imagine any other way at the moment (definitely
in lk 2.4 and it is probably a bit late for lk 2.6).
Is there an upper limit on the size of the cdb you are interested in
(e.g. XDWRITE EXTENDED in SBC-2 is 64 bytes)?
How were you planning to pass the cdb (length > 16) to the kernel?
Doug Gilbert
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Support for CDB length > 16
2003-11-18 9:33 ` Douglas Gilbert
@ 2003-11-18 11:15 ` Liran Schour
2003-11-18 11:44 ` Christoph Hellwig
2003-11-18 11:21 ` Andre Hedrick
1 sibling, 1 reply; 9+ messages in thread
From: Liran Schour @ 2003-11-18 11:15 UTC (permalink / raw)
To: dougg; +Cc: linux-scsi
Doug Gilbert wrote:
> It is hard to imagine any other way at the moment (definitely
> in lk 2.4 and it is probably a bit late for lk 2.6).
> Is there an upper limit on the size of the cdb you are interested in
> (e.g. XDWRITE EXTENDED in SBC-2 is 64 bytes)?
I have an upperlimit of 256 bytes.
> How were you planning to pass the cdb (length > 16) to the kernel?
I am planning to build a filesystem in the kernel that will be over an OSD
SCSI device. This layer will interact directly with the SCSI system.
Thanks,
- Liran
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Support for CDB length > 16
2003-11-18 11:15 ` Liran Schour
@ 2003-11-18 11:44 ` Christoph Hellwig
0 siblings, 0 replies; 9+ messages in thread
From: Christoph Hellwig @ 2003-11-18 11:44 UTC (permalink / raw)
To: Liran Schour; +Cc: dougg, linux-scsi
On Tue, Nov 18, 2003 at 01:15:31PM +0200, Liran Schour wrote:
> > Is there an upper limit on the size of the cdb you are interested in
> > (e.g. XDWRITE EXTENDED in SBC-2 is 64 bytes)?
> I have an upperlimit of 256 bytes.
That's far beyond what we could increase the cmnd buffers to.
>
> > How were you planning to pass the cdb (length > 16) to the kernel?
> I am planning to build a filesystem in the kernel that will be over an OSD
> SCSI device. This layer will interact directly with the SCSI system.
I don't think there's a lot of chance to see your project supported in
mainline kernels. Maybe we'll have to find a way to make it work when
it's ready for mainline submission, but before that you're on your own..
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Support for CDB length > 16
2003-11-18 9:33 ` Douglas Gilbert
2003-11-18 11:15 ` Liran Schour
@ 2003-11-18 11:21 ` Andre Hedrick
1 sibling, 0 replies; 9+ messages in thread
From: Andre Hedrick @ 2003-11-18 11:21 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: Liran Schour, linux-scsi
I suspect this is midlayer injection for SAS.
Andre Hedrick
LAD Storage Consulting Group
On Tue, 18 Nov 2003, Douglas Gilbert wrote:
> Liran Schour wrote:
> >
> > I need a support from the Linux SCSI subsystem for CDB length > 16 byte.
> > Is it possible to do that without recompiling the kernel with a new
> > MAX_COMMAND_SIZE definition.
>
> It is hard to imagine any other way at the moment (definitely
> in lk 2.4 and it is probably a bit late for lk 2.6).
>
> Is there an upper limit on the size of the cdb you are interested in
> (e.g. XDWRITE EXTENDED in SBC-2 is 64 bytes)?
>
> How were you planning to pass the cdb (length > 16) to the kernel?
>
> Doug Gilbert
>
>
> -
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Support for CDB length > 16
2003-11-18 8:49 Support for CDB length > 16 Liran Schour
2003-11-18 9:33 ` Douglas Gilbert
@ 2003-11-18 11:31 ` Christoph Hellwig
2003-11-18 11:46 ` Liran Schour
1 sibling, 1 reply; 9+ messages in thread
From: Christoph Hellwig @ 2003-11-18 11:31 UTC (permalink / raw)
To: Liran Schour; +Cc: linux-scsi
On Tue, Nov 18, 2003 at 10:49:44AM +0200, Liran Schour wrote:
>
>
>
>
> Hi all,
>
> I need a support from the Linux SCSI subsystem for CDB length > 16 byte.
> Is it possible to do that without recompiling the kernel with a new
> MAX_COMMAND_SIZE definition. I assume that I can find an iscsi driver that
> is able to support CDB > 16 byte.
You'd have to enlarge MAX_COMMAND_SIZE, that'S the whole point of it :)
What exactly are you trying to do and for what kernel release? We've
been through increasing it from 12 to 16 at some point in 2.4.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Support for CDB length > 16
2003-11-18 11:31 ` Christoph Hellwig
@ 2003-11-18 11:46 ` Liran Schour
2003-11-18 13:02 ` Douglas Gilbert
0 siblings, 1 reply; 9+ messages in thread
From: Liran Schour @ 2003-11-18 11:46 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-scsi
Christoph Hellwig wrote:
> You'd have to enlarge MAX_COMMAND_SIZE, that'S the whole point of it :)
> What exactly are you trying to do and for what kernel release? We've
> been through increasing it from 12 to 16 at some point in 2.4.
I am trying to find a way to do that without the need to recompile the
kernel.
I am trying to support an OSD device see t10 OSD draft, I think that 2.6 is
my target kernel release.
Thanks,
- Liran
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Support for CDB length > 16
2003-11-18 11:46 ` Liran Schour
@ 2003-11-18 13:02 ` Douglas Gilbert
2003-11-18 17:46 ` Christoph Hellwig
0 siblings, 1 reply; 9+ messages in thread
From: Douglas Gilbert @ 2003-11-18 13:02 UTC (permalink / raw)
To: Liran Schour; +Cc: Christoph Hellwig, linux-scsi
Liran Schour wrote:
>
>
>
> Christoph Hellwig wrote:
>
>
>>You'd have to enlarge MAX_COMMAND_SIZE, that'S the whole point of it :)
>>What exactly are you trying to do and for what kernel release? We've
>>been through increasing it from 12 to 16 at some point in 2.4.
>
>
> I am trying to find a way to do that without the need to recompile the
> kernel.
> I am trying to support an OSD device see t10 OSD draft, I think that 2.6 is
> my target kernel release.
Liran,
Yep, I knew that I'd seen really big SCSI commands somewhere.
OSD, now there is a storage paradigm that doesn't fit
the block subsystem:-)
Perhaps we should starting thinking about kmalloc()ing
scsi_cmnd::cmnd (rather than having it as a fixed array).
The mid-level owns that structure so it can take care
of allocation and de-allocation. We would have to
find code that does sizeof(scsi_cmnd::cmnd) and fix it.
Doug Gilbert
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Support for CDB length > 16
2003-11-18 13:02 ` Douglas Gilbert
@ 2003-11-18 17:46 ` Christoph Hellwig
0 siblings, 0 replies; 9+ messages in thread
From: Christoph Hellwig @ 2003-11-18 17:46 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: Liran Schour, Christoph Hellwig, linux-scsi
> Perhaps we should starting thinking about kmalloc()ing
> scsi_cmnd::cmnd (rather than having it as a fixed array).
> The mid-level owns that structure so it can take care
> of allocation and de-allocation. We would have to
> find code that does sizeof(scsi_cmnd::cmnd) and fix it.
That would be the way to go if we want to support that big commands,
maybe with an pre-allocated array for 12byte commands so that the
fast-path doesn't get slowed down.
But I'm not going to do that for some vapur-ware, we'll need a real-life
application for that.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-11-18 17:46 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-18 8:49 Support for CDB length > 16 Liran Schour
2003-11-18 9:33 ` Douglas Gilbert
2003-11-18 11:15 ` Liran Schour
2003-11-18 11:44 ` Christoph Hellwig
2003-11-18 11:21 ` Andre Hedrick
2003-11-18 11:31 ` Christoph Hellwig
2003-11-18 11:46 ` Liran Schour
2003-11-18 13:02 ` Douglas Gilbert
2003-11-18 17:46 ` Christoph Hellwig
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).