[Bug 7026] CD/DVD burning with USB writer doesn't work

[Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

Doug:

Can you please take a look at this entry in Bugzilla:

	http://bugzilla.kernel.org/show_bug.cgi?id=7026

The important part starts at Comment 21; in particular the last two 
comments from Joerg Schilling and me are relevant to the SG driver.

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Mon, 2006-12-04 at 15:11 -0500, Alan Stern wrote:
> Can you please take a look at this entry in Bugzilla:
> 
> 	http://bugzilla.kernel.org/show_bug.cgi?id=7026
> 
> The important part starts at Comment 21; in particular the last two 
> comments from Joerg Schilling and me are relevant to the SG driver.

The only comment I'd have is that your last path is too convoluted.  For
any cdrecord -dev=/dev/<block dev>

Then 

/sys/block/<block dev>/queue/max_sectors_kb 

should work just fine.

For the corner cases where /dev/<block dev> isn't the canonical name,
you can find the actual /sys/block/<name> by getting the major:minor and
scanning through /sys/block/*/dev

The only other thing I'd note is that there's no connection between this
value and the one returned by SG_GET_RESERVED_SIZE.  The former is the
max sectors per request.  The latter is the size of the internal buffer
used to build sg lists.

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

I decided to do this by email instead of bugzilla so that it would be 
visible to everyone on the linux-scsi mailing list.

Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026

To recap: Joerg Schilling needs to be able to retrieve the max_sectors 
value for a SCSI device's request queue.  Doing it via sysfs is rather 
clumsy, especially when only a file descriptor is available and not the 
device name.  He has asked for an ioctl interface to provide the 
information.

Is the patch below acceptable?

Alan Stern



Index: usb-2.6/block/scsi_ioctl.c
===================================================================
--- usb-2.6.orig/block/scsi_ioctl.c
+++ usb-2.6/block/scsi_ioctl.c
@@ -97,6 +97,11 @@ static int sg_set_reserved_size(request_
 	return 0;
 }
 
+static int sg_get_max_transfer_length(request_queue_t *q, int __user *p)
+{
+	return put_user(q->max_sectors << 9, p);
+}
+
 /*
  * will always return that we are ATAPI even for a real SCSI drive, I'm not
  * so sure this is worth doing anything about (why would you care??)
@@ -558,6 +563,9 @@ int scsi_cmd_ioctl(struct file *file, st
 		case SG_SET_RESERVED_SIZE:
 			err = sg_set_reserved_size(q, arg);
 			break;
+		case SG_GET_MAX_TRANSFER_LENGTH:
+			err = sg_get_max_transfer_length(q, arg);
+			break;
 		case SG_EMULATED_HOST:
 			err = sg_emulated_host(q, arg);
 			break;
Index: usb-2.6/drivers/scsi/sg.c
===================================================================
--- usb-2.6.orig/drivers/scsi/sg.c
+++ usb-2.6/drivers/scsi/sg.c
@@ -927,6 +927,11 @@ sg_ioctl(struct inode *inode, struct fil
 	case SG_GET_RESERVED_SIZE:
 		val = (int) sfp->reserve.bufflen;
 		return put_user(val, ip);
+	case SG_GET_MAX_TRANSFER_LENGTH:
+		if (sdp->detached || !sdp->device->request_queue)
+			return -ENODEV;
+		val = sdp->device->request_queue->max_sectors << 9;
+		return put_user(val, ip);
 	case SG_SET_COMMAND_Q:
 		result = get_user(val, ip);
 		if (result)
Index: usb-2.6/include/scsi/sg.h
===================================================================
--- usb-2.6.orig/include/scsi/sg.h
+++ usb-2.6/include/scsi/sg.h
@@ -219,6 +219,8 @@ typedef struct sg_req_info { /* used by 
 /* yields scsi midlevel's access_count for this SCSI device */
 #define SG_GET_ACCESS_COUNT 0x2289  
 
+/* Yields the SCSI device queue's max_sector value, in bytes */
+#define SG_GET_MAX_TRANSFER_LENGTH 0x228a
 
 #define SG_SCATTER_SZ (8 * 4096)
 /* Largest size (in bytes) a single scatter-gather list element can have.

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Tue, 2006-12-05 at 15:52 -0500, Alan Stern wrote:
> I decided to do this by email instead of bugzilla so that it would be 
> visible to everyone on the linux-scsi mailing list.
> 
> Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
> 
> To recap: Joerg Schilling needs to be able to retrieve the max_sectors 
> value for a SCSI device's request queue.  Doing it via sysfs is rather 
> clumsy, especially when only a file descriptor is available and not the 
> device name.  He has asked for an ioctl interface to provide the 
> information.

But how did he get the file descriptor?  He opened a device name, which
could have been used to get the sysfs file.

> Is the patch below acceptable?

Really, no.  The parameter you're fishing for is a block parameter, not
a SCSI parameter ... it should really be a block ioctl if we have to
have an ioctl at all.

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

James Bottomley <James.Bottomley@SteelEye.com> wrote:

> > Is the patch below acceptable?
>
> Really, no.  The parameter you're fishing for is a block parameter, not
> a SCSI parameter ... it should really be a block ioctl if we have to
> have an ioctl at all.

I am afraid, you seem to missunderstand things.

This parameter is not related to something you may call "block layer", it is 
rather related to the low level SCSI transport. If the value is stored in a 
higher layer, it is not stored in the layer where it belongs to.

If you like to take care of clean interfaces, make sure that this parameter is 
moved to the right place in the code.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Tue, 2006-12-05 at 23:46 +0100, Joerg Schilling wrote:
> I am afraid, you seem to missunderstand things.
> 
> This parameter is not related to something you may call "block layer", it is 
> rather related to the low level SCSI transport. If the value is stored in a 
> higher layer, it is not stored in the layer where it belongs to.
> 
> If you like to take care of clean interfaces, make sure that this parameter is 
> moved to the right place in the code.

The patch Alan posted is returning the max_sectors count from the block
layer, which is a block, not a SCSI parameter ... so what is it that you
actually want?

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

James Bottomley <James.Bottomley@SteelEye.com> wrote:

> On Tue, 2006-12-05 at 23:46 +0100, Joerg Schilling wrote:
> > I am afraid, you seem to missunderstand things.
> > 
> > This parameter is not related to something you may call "block layer", it is 
> > rather related to the low level SCSI transport. If the value is stored in a 
> > higher layer, it is not stored in the layer where it belongs to.
> > 
> > If you like to take care of clean interfaces, make sure that this parameter is 
> > moved to the right place in the code.
>
> The patch Alan posted is returning the max_sectors count from the block
> layer, which is a block, not a SCSI parameter ... so what is it that you
> actually want?

Well, accept the patch if it works. And in case that you don't like it, make 
sure that the _parameter_ is moved to where it belongs: to the low level 
transport layer.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
> Well, accept the patch if it works.

It's not about work/not work: it's about correctness.

>  And in case that you don't like it, make sure that the _parameter_ is
> moved to where it belongs: to the low level transport layer.

It's not a low level property; it's a property of the generic queue,
namely the maximum request size.  It exists for devices independent of
SCSI (i.e. you'll want it for IDE and weirder transport attachment CDs
as well).

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Douglas Gilbert]

James Bottomley wrote:
> On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
>> Well, accept the patch if it works.
> 
> It's not about work/not work: it's about correctness.
> 
>>  And in case that you don't like it, make sure that the _parameter_ is
>> moved to where it belongs: to the low level transport layer.
> 
> It's not a low level property; it's a property of the generic queue,
> namely the maximum request size.  It exists for devices independent of
> SCSI (i.e. you'll want it for IDE and weirder transport attachment CDs
> as well).

Too much smoke and mirrors.

That maximum request size comes from the transport ** and
in many cases is a kludge between maximum, optimal and
defensive. The block paradigm is wrong for a pass through
because it requests transports to guess a "maximum",
trying to head off errors that the block layer isn't
particularly well equipped to handle at run time.

On the other hand a pass through gets layered error reporting.
So if a host (and/or its LLD driver) doesn't like the
size (or shape) of data to be sent/received with a
command, then it can say so (and I don't mean EIO or
ENOMEM). That leaves the ball in the court of the pass
through user. Perhaps in this case sysfs could be
useful. The problem may be transient.


** as always the OS could have run out of resources (e.g. ram)
   but again that is most likely transient.

Doug Gilbert

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Mike Christie]

Douglas Gilbert wrote:
> James Bottomley wrote:
>> On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
>>> Well, accept the patch if it works.
>> It's not about work/not work: it's about correctness.
>>
>>>  And in case that you don't like it, make sure that the _parameter_ is
>>> moved to where it belongs: to the low level transport layer.
>> It's not a low level property; it's a property of the generic queue,
>> namely the maximum request size.  It exists for devices independent of
>> SCSI (i.e. you'll want it for IDE and weirder transport attachment CDs
>> as well).
> 
> Too much smoke and mirrors.
> 
> That maximum request size comes from the transport ** and
> in many cases is a kludge between maximum, optimal and
> defensive. The block paradigm is wrong for a pass through
> because it requests transports to guess a "maximum",
> trying to head off errors that the block layer isn't
> particularly well equipped to handle at run time.
> 
> On the other hand a pass through gets layered error reporting.
> So if a host (and/or its LLD driver) doesn't like the
> size (or shape) of data to be sent/received with a


For iscsi, we could negotiate a value like MaxBurstLength which says
don't send commands with a payload larger than that size. I would guess
other transports have something similar. We have to check or make sure
we do not get commands larger than this somewhere. It is nice if some
common layer could do this for us. Cards have a scatterlist limits and
having them checked before they get to the driver for everyone is nice.
I agree using and being limited to SG_ALL is a little strange since it
is a odd size and having to recompile your kernel to get up to that
limit is a pain in the butt, but that is not a problem with using the
block layer. Those are scsi layer variables and I think those values can
be changed.

Is the main gripe over max sectors? I agree max sectors is odd because
we do not know what that value means in some cases for pass through and
what that real limit is for many drivers. Because the other values that
we check in the block layer to create the scatterlist and request, seem
worthwhile to check as early as possible and if we checked them at the
driver level for every driver how would the test or return value be
different? I think this is the part I do not fully understand when this
keeps popping up.

Currently the LLD cannot tell you that it cannot handle a command
because it was just too darn large any more than the block layer can.
One would return -EINVAL or -ENOMEM and the other would return lots of
different values because it depends on the driver and none of them tell
you that a specific limit was reached.

All we really want is the underlying mapping and scatterlist building
code but without some checks like max sectors and we want some new error
values. I will leave the debate over whether those should be checked to
you guys :) I only want to help on getting more info to the user and I
do not think we should have duplicated code doing the same thing except
one checks max_hw_sectors and the other does not. Oh yeah, but on that
note, in the original patches I did not check for values like max
sectors. I later changed this to checking for max hw sectors. You could
modify the REQ_TYPE_BLOCK_PC checks that I added to not test anything
instead of values like max_hw_sectors again (I am just saying it is
possible in the code not).

For the problem of sending error values that are not useful and leaving
the user in the dark we can still use the block layer helpers and not
have to add so many checks to the LLDs by modifying them to return
BLKERR values that are more descriptive like here:

http://kernel.org/git/?p=linux/kernel/git/mnc/linux-2.6-iscsi.git;a=blob;h=c8c20df124e58d04f90e74dea8d7880016f8a5df;hb=multipath;f=include/linux/blkdev.h

In that code that I am doing to move the dm hw_handlers to scsi we need
to return something more informative than -Exyz, so I added BLKERR
values and one day I will convert all the block driver again and
convince Jens we need it :) For something like using blk_rq_map_user to
map/copy the data, instead of returning -EINVAL when we hit a limit I
want to return BLKERR_TOO_MANY_SEGMENTS, BLKERR_TOO_MANY_SECTORS,
BLKERR_SEGMENT_TOO_LARGE, etc just like if the LLD was to return a new
DID_* error value to tell them the same thing.

Alternatively, if we do start not checking values like max sectors and
send requests down to the drivers, the block layer mapping functions can
be modified to not check certain values and LLDs/scsi-ml can return
these BLKERR values all the way up to sg/bsg/scsi_ioctl.c for values
that they need to check.

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Wed, 6 Dec 2006, Mike Christie wrote:

> Alternatively, if we do start not checking values like max sectors and
> send requests down to the drivers, the block layer mapping functions can
> be modified to not check certain values and LLDs/scsi-ml can return
> these BLKERR values all the way up to sg/bsg/scsi_ioctl.c for values
> that they need to check.

I bet in many cases the LLD depends on the higher layers to filter out 
transfers that are too large.  Duplicating all those tests in all the LLDs 
seems like a waste.

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

Alan Stern <stern@rowland.harvard.edu> wrote:

> On Wed, 6 Dec 2006, Mike Christie wrote:
>
> > Alternatively, if we do start not checking values like max sectors and
> > send requests down to the drivers, the block layer mapping functions can
> > be modified to not check certain values and LLDs/scsi-ml can return
> > these BLKERR values all the way up to sg/bsg/scsi_ioctl.c for values
> > that they need to check.
>
> I bet in many cases the LLD depends on the higher layers to filter out 
> transfers that are too large.  Duplicating all those tests in all the LLDs 
> seems like a waste.

Once you are done with the implementation details, could you tell me what you 
decided to add for the final implementation?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Thu, 7 Dec 2006, Joerg Schilling wrote:

> Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > On Wed, 6 Dec 2006, Mike Christie wrote:
> >
> > > Alternatively, if we do start not checking values like max sectors and
> > > send requests down to the drivers, the block layer mapping functions can
> > > be modified to not check certain values and LLDs/scsi-ml can return
> > > these BLKERR values all the way up to sg/bsg/scsi_ioctl.c for values
> > > that they need to check.
> >
> > I bet in many cases the LLD depends on the higher layers to filter out 
> > transfers that are too large.  Duplicating all those tests in all the LLDs 
> > seems like a waste.
> 
> Once you are done with the implementation details, could you tell me what you 
> decided to add for the final implementation?

I will.  If everything goes well then BLKSECTGET will be made to work with 
the SCSI-Generic interface as well as with the usual block device files, 
so you'll be able to use it with any file descriptor for a CD or DVD 
drive.

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

Alan Stern <stern@rowland.harvard.edu> wrote:

> I will.  If everything goes well then BLKSECTGET will be made to work with 
> the SCSI-Generic interface as well as with the usual block device files, 
> so you'll be able to use it with any file descriptor for a CD or DVD 
> drive.

Coud you please inform me if this has been done?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Fri, 8 Dec 2006, Joerg Schilling wrote:

> Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > I will.  If everything goes well then BLKSECTGET will be made to work with 
> > the SCSI-Generic interface as well as with the usual block device files, 
> > so you'll be able to use it with any file descriptor for a CD or DVD 
> > drive.
> 
> Coud you please inform me if this has been done?

I will let you know and I will make sure you receive the patch.

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Mike Christie]

Mike Christie wrote:
> Douglas Gilbert wrote:
>> James Bottomley wrote:
>>> On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
>>>> Well, accept the patch if it works.
>>> It's not about work/not work: it's about correctness.
>>>
>>>>  And in case that you don't like it, make sure that the _parameter_ is
>>>> moved to where it belongs: to the low level transport layer.
>>> It's not a low level property; it's a property of the generic queue,
>>> namely the maximum request size.  It exists for devices independent of
>>> SCSI (i.e. you'll want it for IDE and weirder transport attachment CDs
>>> as well).
>> Too much smoke and mirrors.
>>
>> That maximum request size comes from the transport ** and
>> in many cases is a kludge between maximum, optimal and
>> defensive. The block paradigm is wrong for a pass through
>> because it requests transports to guess a "maximum",
>> trying to head off errors that the block layer isn't
>> particularly well equipped to handle at run time.
>>
>> On the other hand a pass through gets layered error reporting.
>> So if a host (and/or its LLD driver) doesn't like the
>> size (or shape) of data to be sent/received with a
> 
> 
> For iscsi, we could negotiate a value like MaxBurstLength which says
> don't send commands with a payload larger than that size. I would guess
> other transports have something similar. We have to check or make sure
> we do not get commands larger than this somewhere. It is nice if some
> common layer could do this for us. Cards have a scatterlist limits and
> having them checked before they get to the driver for everyone is nice.
> I agree using and being limited to SG_ALL is a little strange since it
> is a odd size and having to recompile your kernel to get up to that
> limit is a pain in the butt, but that is not a problem with using the
> block layer. Those are scsi layer variables and I think those values can
> be changed.
> 
> Is the main gripe over max sectors? I agree max sectors is odd because
> we do not know what that value means in some cases for pass through and
> what that real limit is for many drivers. Because the other values that
> we check in the block layer to create the scatterlist and request, seem
> worthwhile to check as early as possible and if we checked them at the
> driver level for every driver how would the test or return value be
> different? I think this is the part I do not fully understand when this
> keeps popping up.
> 

Oh yeah the exception I am thinking about may not be max sectors exactly
but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs
are supposed to be translating that iscsi limit to max_sectors in which
case we are talking about the same thing. For this limit we do not want
a FS or pass through request with more data than MaxBurstLength bytes.
If it is different than max_hw_sectors, we could add q->max_request_size
and check this in the block mapping and request building functions, but
the error value would be generic like maybe BLKERR_REQUEST_TOO_LARGE.
You would not be able to tell the user that specifically the request was
larger than the iscsi MaxBurstLength.

I am not sure how this fits into the argument, since there is no
guessing with it. The block layer handles this nicely for FS requests by
breaking up requests into the correct size. The limit also applies to
pass through requests and we can get a error indicating it is too large.
The draw back is of course lack of information to the user or upper
layer and it seems you guys are arguing where this type check belongs.

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Jeremy Linton]

On Wednesday 06 December 2006 16:50, Mike Christie wrote:
> > For iscsi, we could negotiate a value like MaxBurstLength which says
> > don't send commands with a payload larger than that size. I would guess
> > other transports have something similar. We have to check or make sure
...
> Oh yeah the exception I am thinking about may not be max sectors exactly
> but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs
> are supposed to be translating that iscsi limit to max_sectors in which
> case we are talking about the same thing. For this limit we do not want

	Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max transfer 
size, it simply is the amount of data that can be sent without a R2T. If the 
transfer is larger then you have to wait for the R2T. In practice it ends up 
controlling the _minimum_ amount of buffer space that needs to be available 
_before_ the transfer starts, otherwise performace sucks. 

-- 
PHB REQ:

Privileged or confidential information may be contained in this message.
If you are not the addressee of this message please notify the sender by
return email and thereafter delete the message.  You may not use, copy,
disclose or rely on the information contained in this message.  Internet
e-mail may be susceptible to data corruption, interception and
unauthorized amendment for which Gresham does not accept liability.
While we have taken reasonable precautions to ensure that this e-mail
and any attachments have been swept for viruses, Gresham does not accept 
liability for any damage sustained as a result of viruses.  Statements
in this message that do not relate to the business of Gresham are
neither given nor endorsed by the company or its directors.  A list of
Gresham's directors is available on our web site:
<www.gresham-computing.com>   

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Jeremy Linton]

On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
> > > For iscsi, we could negotiate a value like MaxBurstLength which says
> > > don't send commands with a payload larger than that size. I would guess
> > > other transports have something similar. We have to check or make sure
>
> ...
>
> > Oh yeah the exception I am thinking about may not be max sectors exactly
> > but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs
> > are supposed to be translating that iscsi limit to max_sectors in which
> > case we are talking about the same thing. For this limit we do not want
>
> 	Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max
> transfer size, it simply is the amount of data that can be sent without a
> R2T. If the transfer is larger then you have to wait for the R2T. In
> practice it ends up controlling the _minimum_ amount of buffer space that
> needs to be available _before_ the transfer starts, otherwise performace
> sucks.
	Whops, Slight clarification, the MaxBurstLength is the max sent between R2T's 
what I described above is closer to the FirstBurstLength. What you guys are 
describing might better be the MaxRecvDataSegmentLength, but not really since 
that parameter should be hidden within the iSCSI driver.

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Mike Christie]

Jeremy Linton wrote:
> On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
>> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
>>>> For iscsi, we could negotiate a value like MaxBurstLength which says
>>>> don't send commands with a payload larger than that size. I would guess
>>>> other transports have something similar. We have to check or make sure
>> ...
>>
>>> Oh yeah the exception I am thinking about may not be max sectors exactly
>>> but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs
>>> are supposed to be translating that iscsi limit to max_sectors in which
>>> case we are talking about the same thing. For this limit we do not want
>> 	Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max
>> transfer size, it simply is the amount of data that can be sent without a
>> R2T. If the transfer is larger then you have to wait for the R2T. In
>> practice it ends up controlling the _minimum_ amount of buffer space that
>> needs to be available _before_ the transfer starts, otherwise performace
>> sucks.
> 	Whops, Slight clarification, the MaxBurstLength is the max sent between R2T's 
> what I described above is closer to the FirstBurstLength. What you guys are 

I should have clarified this would have been a workaround for some bad
targets, but I hoped could be more useful for other transports that
needed it for valid reasons.

The MaxBurstLength length limits what can be transferred in sequence of
data-in pdus _or_ like you describe a solicited data out sequence,
doesn't it (see section 12.13)? We are more concerned with the data-in
sequence here. If we have a READ of 1048576 bytes and a
MaxBurstLength=524288 some targets were getting confused and instead of
splitting up the transfer into multiple sequences it would assume there
could be one sequence. So for those targets the MaxBurstLength becomes
the max we can read and targets do fun things like drop connections if
we send them something larger.

Oh the flip side, targets also end up sending us more than
MaxBurstLength bytes between r2ts. The initiator just prints an error
and makes sure it does not go out of bounds because this is so common.
We have to handle lots of fun bugs in targets. I bet targets do lots of
weird things to handle our mess ups too :)

And a sequence does not necessarily mean one pdu so
MaxRecvDataSegmentLength does not matter in the discussion of max
request size here (as long as we are talking about good behaving targets
:)).

Sorry for the confusion.

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Mike Christie]

Mike Christie wrote:
> Jeremy Linton wrote:
>> On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
>>> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
>>>>> For iscsi, we could negotiate a value like MaxBurstLength which says
>>>>> don't send commands with a payload larger than that size. I would guess
>>>>> other transports have something similar. We have to check or make sure
>>> ...
>>>
>>>> Oh yeah the exception I am thinking about may not be max sectors exactly
>>>> but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs
>>>> are supposed to be translating that iscsi limit to max_sectors in which
>>>> case we are talking about the same thing. For this limit we do not want
>>> 	Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max
>>> transfer size, it simply is the amount of data that can be sent without a
>>> R2T. If the transfer is larger then you have to wait for the R2T. In
>>> practice it ends up controlling the _minimum_ amount of buffer space that
>>> needs to be available _before_ the transfer starts, otherwise performace
>>> sucks.
>> 	Whops, Slight clarification, the MaxBurstLength is the max sent between R2T's 
>> what I described above is closer to the FirstBurstLength. What you guys are 
> 
> I should have clarified this would have been a workaround for some bad
> targets, but I hoped could be more useful for other transports that
> needed it for valid reasons.
> 
> The MaxBurstLength length limits what can be transferred in sequence of
> data-in pdus _or_ like you describe a solicited data out sequence,
> doesn't it (see section 12.13)? We are more concerned with the data-in
> sequence here. If we have a READ of 1048576 bytes and a
> MaxBurstLength=524288 some targets were getting confused and instead of
> splitting up the transfer into multiple sequences it would assume there
> could be one sequence. So for those targets the MaxBurstLength becomes
> the max we can read and targets do fun things like drop connections if
> we send them something larger.
> 
> Oh the flip side, targets also end up sending us more than
> MaxBurstLength bytes between r2ts. 

And actually, I think there was a target that bugged out when we tried
to send it a WRITE that was larger than MaxBurstLength. I do not
remember though.

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Mike Christie]

Mike Christie wrote:
> Jeremy Linton wrote:
>> On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
>>> On Wednesday 06 December 2006 16:50, Mike Christie wrote:
>>>>> For iscsi, we could negotiate a value like MaxBurstLength which says
>>>>> don't send commands with a payload larger than that size. I would guess
>>>>> other transports have something similar. We have to check or make sure
>>> ...
>>>
>>>> Oh yeah the exception I am thinking about may not be max sectors exactly
>>>> but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs
>>>> are supposed to be translating that iscsi limit to max_sectors in which
>>>> case we are talking about the same thing. For this limit we do not want
>>> 	Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max
>>> transfer size, it simply is the amount of data that can be sent without a
>>> R2T. If the transfer is larger then you have to wait for the R2T. In
>>> practice it ends up controlling the _minimum_ amount of buffer space that
>>> needs to be available _before_ the transfer starts, otherwise performace
>>> sucks.
>> 	Whops, Slight clarification, the MaxBurstLength is the max sent between R2T's 
>> what I described above is closer to the FirstBurstLength. What you guys are 
> 
> I should have clarified this would have been a workaround for some bad
> targets, but I hoped could be more useful for other transports that
> needed it for valid reasons.
> 
> The MaxBurstLength length limits what can be transferred in sequence of
> data-in pdus _or_ like you describe a solicited data out sequence,
> doesn't it (see section 12.13)? We are more concerned with the data-in
> sequence here. If we have a READ of 1048576 bytes and a
> MaxBurstLength=524288 some targets were getting confused and instead of
> splitting up the transfer into multiple sequences it would assume there
> could be one sequence. So for those targets the MaxBurstLength becomes
> the max we can read and targets do fun things like drop connections if
> we send them something larger.
> 
> Oh the flip side, targets also end up sending us more than
> MaxBurstLength bytes between r2ts. The initiator just prints an error
> and makes sure it does not go out of bounds because this is so common.
> We have to handle lots of fun bugs in targets. I bet targets do lots of
> weird things to handle our mess ups too :)
> 
> And a sequence does not necessarily mean one pdu so
> MaxRecvDataSegmentLength does not matter in the discussion of max
> request size here (as long as we are talking about good behaving targets
> :)).
> 

Oh, where this transport level limit vs hw or queue vs software limit
might also come in is if we do transport level requests through bsg and
that ends up using the block layer. For that, if we wanted to send a
nop-out with data we would have to make sure it is less than
MaxRecvDataSegmentLength, right? I am not sure how all that will work
out. Would that be some queue limit like a q->max_transport_request_size
because we are using the queue and requests for transport level
requests, or would we only check this at the iscsi level and return some
new value to indicate the request was too large because of a transport
limit?

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

James Bottomley <James.Bottomley@SteelEye.com> wrote:

> On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
> > Well, accept the patch if it works.
>
> It's not about work/not work: it's about correctness.
>
> >  And in case that you don't like it, make sure that the _parameter_ is
> > moved to where it belongs: to the low level transport layer.
>
> It's not a low level property; it's a property of the generic queue,
> namely the maximum request size.  It exists for devices independent of
> SCSI (i.e. you'll want it for IDE and weirder transport attachment CDs
> as well).

It is a DMA property, so it is a low level property. The fact that the 
parameter is held somewhere else does not change this.

BTW: I received a positive test result from a user, so the patch really 
fixes the problems and we should use it.
Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Tue, 5 Dec 2006, Joerg Schilling wrote:

> If the number in "sectors" is not a value in sectors but a value in 512 byte
> units, it looks OK.

That's right.  This is one of those places where the kernel converts
between the hardware's actual sector size and a fictitious 512-byte sector
size.

> Is this value correct for all "host adaptors"?

Yes.


On Tue, 5 Dec 2006, James Bottomley wrote:

> > To recap: Joerg Schilling needs to be able to retrieve the max_sectors 
> > value for a SCSI device's request queue.  Doing it via sysfs is rather 
> > clumsy, especially when only a file descriptor is available and not the 
> > device name.  He has asked for an ioctl interface to provide the 
> > information.
> 
> But how did he get the file descriptor?  He opened a device name, which
> could have been used to get the sysfs file.

The device name was probably something like /dev/sg0.  This doesn't easily
permit one to find the corresponding sysfs filename for the real
underlying device, although it can be done with difficulty.  (That's why I
used the excessively-ornate sysfs pathname in the Bugzilla entry.)  It
certainly wouldn't be as easy as using an ioctl.

It wouldn't be as uniform either.  The search through sysfs would have to 
be different depending on whether the device name was /dev/sr0 or 
/dev/sg0.

> > Is the patch below acceptable?
> 
> Really, no.  The parameter you're fishing for is a block parameter, not
> a SCSI parameter ... it should really be a block ioctl if we have to
> have an ioctl at all.

I could easily enough rewrite the patch to put the ioctl somewhere else
(although I'm not quite sure exactly where would be best).  But do
non-block devices have request queues?  What about the points that Doug
raised:

On Tue, 5 Dec 2006, Douglas Gilbert wrote:

> Apart from sensibly yielding the max size in bytes, your patch
> has the added benefit of allowing non-block devices (e.g. tape,
> processor and enclosure services) to find out what limit the
> OS/host has placed on each command's maximum transfer size.
>  
> If you manage to get that ioctl in, then ungrateful people
> will ask for the corresponding "set" operation as well.
> 
> 
> To illustrate the /sys mess look at naming of the sysfs approach
> to this problem. For example:
>   /sys/block/sde/queue/max_sectors_kb
>     - it is not only a "block" property
>     - sde is an "end device" and suggests information from that
>       device's Block Limits VPD page, actually it is a limit
>       imposed by the OS and the host used to access that device
>     - what has "queue" got to do with it?
>     - "max_sectors_kb" should have units of bytes

In addition to all of these points, there remains the peculiar location of 
the SG_ ioctls.  They are implemented it two places in the kernel: 
block/scsi_ioctl.c and drivers/scsi/sg.c.  And the two implementations of 
e.g. SG_SET_RESERVED_SIZE don't even do the same thing!


On Wed, 6 Dec 2006, Joerg Schilling wrote:

> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> 
> > On Tue, 2006-12-05 at 23:46 +0100, Joerg Schilling wrote:
> > > I am afraid, you seem to missunderstand things.
> > > 
> > > This parameter is not related to something you may call "block layer", it is 
> > > rather related to the low level SCSI transport. If the value is stored in a 
> > > higher layer, it is not stored in the layer where it belongs to.
> > > 
> > > If you like to take care of clean interfaces, make sure that this parameter is 
> > > moved to the right place in the code.
> >
> > The patch Alan posted is returning the max_sectors count from the block
> > layer, which is a block, not a SCSI parameter ... so what is it that you
> > actually want?
> 
> Well, accept the patch if it works. And in case that you don't like it, make 
> sure that the _parameter_ is moved to where it belongs: to the low level 
> transport layer.

The problem is that this parameter is used in _both_ the low-level
transport and the mid-level block & request-queuing code.  The transport
obviously has to be aware of the maximum transfer size, and the
queue-management code has to know into what size units I/O requests should
be broken up.  So I don't think it makes sense to say that the parameter
"belongs" to one layer or the other.

Given all this, it seems to be a good idea to add this ioctl.  The only 
question is where?

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Wed, 2006-12-06 at 11:32 -0500, Alan Stern wrote:
> > But how did he get the file descriptor?  He opened a device name, which
> > could have been used to get the sysfs file.
> 
> The device name was probably something like /dev/sg0.  This doesn't easily
> permit one to find the corresponding sysfs filename for the real
> underlying device, although it can be done with difficulty.  (That's why I
> used the excessively-ornate sysfs pathname in the Bugzilla entry.)  It
> certainly wouldn't be as easy as using an ioctl.
> 
> It wouldn't be as uniform either.  The search through sysfs would have to 
> be different depending on whether the device name was /dev/sr0 or 
> /dev/sg0.

Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've
tried to get some for some of my older boxes.  Most of them nowadays are
IDE attachments, which don't have a /dev/sg node.  So /dev/sg is really
the legacy mode for burning.  The correct way to do it today is to use
the actual device name ... then you don't have to worry about what the
transport is any more.

> > > Is the patch below acceptable?
> > 
> > Really, no.  The parameter you're fishing for is a block parameter, not
> > a SCSI parameter ... it should really be a block ioctl if we have to
> > have an ioctl at all.
> 
> I could easily enough rewrite the patch to put the ioctl somewhere else
> (although I'm not quite sure exactly where would be best).  But do
> non-block devices have request queues?  What about the points that Doug
> raised:

All CD/DVD burners are block devices, which is the problem set under
discussion.

> On Tue, 5 Dec 2006, Douglas Gilbert wrote:
> 
> > Apart from sensibly yielding the max size in bytes, your patch
> > has the added benefit of allowing non-block devices (e.g. tape,
> > processor and enclosure services) to find out what limit the
> > OS/host has placed on each command's maximum transfer size.

They all possess block queues, yes, so we should really allow access to
the block ioctls for them.

> > If you manage to get that ioctl in, then ungrateful people
> > will ask for the corresponding "set" operation as well.
> > 
> > 
> > To illustrate the /sys mess look at naming of the sysfs approach
> > to this problem. For example:
> >   /sys/block/sde/queue/max_sectors_kb
> >     - it is not only a "block" property
> >     - sde is an "end device" and suggests information from that
> >       device's Block Limits VPD page, actually it is a limit
> >       imposed by the OS and the host used to access that device
> >     - what has "queue" got to do with it?
> >     - "max_sectors_kb" should have units of bytes
> 
> In addition to all of these points, there remains the peculiar location of 
> the SG_ ioctls.  They are implemented it two places in the kernel: 
> block/scsi_ioctl.c and drivers/scsi/sg.c.  And the two implementations of 
> e.g. SG_SET_RESERVED_SIZE don't even do the same thing!

I have no idea why the block layer even implements
SG_SET_RESERVED_SIZE ... I suspect it was some legacy application
compatibility problem, so it probably can be eliminated.

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Wed, 6 Dec 2006, James Bottomley wrote:

> Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've
> tried to get some for some of my older boxes.  Most of them nowadays are
> IDE attachments, which don't have a /dev/sg node.  So /dev/sg is really
> the legacy mode for burning.

Well, there are still a lot of legacy devices out there.

>  The correct way to do it today is to use
> the actual device name ... then you don't have to worry about what the
> transport is any more.

> > I could easily enough rewrite the patch to put the ioctl somewhere else
> > (although I'm not quite sure exactly where would be best).  But do
> > non-block devices have request queues?  What about the points that Doug
> > raised:
> 
> All CD/DVD burners are block devices, which is the problem set under
> discussion.

Fair enough.

> > On Tue, 5 Dec 2006, Douglas Gilbert wrote:
> > 
> > > Apart from sensibly yielding the max size in bytes, your patch
> > > has the added benefit of allowing non-block devices (e.g. tape,
> > > processor and enclosure services) to find out what limit the
> > > OS/host has placed on each command's maximum transfer size.
> 
> They all possess block queues, yes, so we should really allow access to
> the block ioctls for them.

> I have no idea why the block layer even implements
> SG_SET_RESERVED_SIZE ... I suspect it was some legacy application
> compatibility problem, so it probably can be eliminated.

Let's leave that for a separate patch.


It turns out that for block device files we don't need to change anything.
The BLKSECTGET ioctl already does almost exactly what we want:

	int n;

	if (ioctl(fd, BLKSECTGET, &n) == 0)
		max_transfer_size = n * 512;

So only the legacy sg character-device files need attention, which means 
that only the part of the patch affecting sg.c is necessary.  The new 
SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the block 
layer -- just as SG_[SG]ET_RESERVED_SIZE should be.

How does that sound?

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Wed, 2006-12-06 at 12:21 -0500, Alan Stern wrote:
> So only the legacy sg character-device files need attention, which
> means 
> that only the part of the patch affecting sg.c is necessary.  The new 
> SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the
> block 
> layer -- just as SG_[SG]ET_RESERVED_SIZE should be.
> 
> How does that sound?

Actually, I'd just connect sg up to the block ioctl ... it has a block
queue and valid parameters, so BLKSECTGET will work for it as well.

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Wed, 6 Dec 2006, James Bottomley wrote:

> On Wed, 2006-12-06 at 12:21 -0500, Alan Stern wrote:
> > So only the legacy sg character-device files need attention, which
> > means 
> > that only the part of the patch affecting sg.c is necessary.  The new 
> > SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the
> > block 
> > layer -- just as SG_[SG]ET_RESERVED_SIZE should be.
> > 
> > How does that sound?
> 
> Actually, I'd just connect sg up to the block ioctl ... it has a block
> queue and valid parameters, so BLKSECTGET will work for it as well.

I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set, 
and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue().  So 
it won't work with sg, which uses character device nodes.

How about adding BLKSECTGET to the list of commands accepted by 
sg_ioctl()?

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
> I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set, 
> and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue().  So 
> it won't work with sg, which uses character device nodes.

Well, even sg has the queue ... and what we're looking for are the queue
parameters.  In block/ioctl.c the bdev is just used for getting the
queue parameters (mainly via bdev->bd_disk->queue), so I could see if
Jens might be amenable to refactoring the queue ioctls so we can get at
them simply with a struct request_queue parameter.

> How about adding BLKSECTGET to the list of commands accepted by 
> sg_ioctl()?

That's certainly a possible hack ... although I'd prefer to see the full
queue ioctls exposed.

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Wed, 6 Dec 2006, James Bottomley wrote:

> On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
> > I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set, 
> > and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue().  So 
> > it won't work with sg, which uses character device nodes.
> 
> Well, even sg has the queue ... and what we're looking for are the queue
> parameters.  In block/ioctl.c the bdev is just used for getting the
> queue parameters (mainly via bdev->bd_disk->queue),

That's true for several of the ioctls but not all of them.

>  so I could see if
> Jens might be amenable to refactoring the queue ioctls so we can get at
> them simply with a struct request_queue parameter.

That would be fine with me.  Could you go ahead and ask Jens?

> > How about adding BLKSECTGET to the list of commands accepted by 
> > sg_ioctl()?
> 
> That's certainly a possible hack ... although I'd prefer to see the full
> queue ioctls exposed.

I agree; it's better to keep things in one place rather than to duplicate
them.

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Wed, 6 Dec 2006, James Bottomley wrote:

> On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
> > I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set, 
> > and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue().  So 
> > it won't work with sg, which uses character device nodes.
> 
> Well, even sg has the queue ... and what we're looking for are the queue
> parameters.  In block/ioctl.c the bdev is just used for getting the
> queue parameters (mainly via bdev->bd_disk->queue), so I could see if
> Jens might be amenable to refactoring the queue ioctls so we can get at
> them simply with a struct request_queue parameter.
> 
> > How about adding BLKSECTGET to the list of commands accepted by 
> > sg_ioctl()?
> 
> That's certainly a possible hack ... although I'd prefer to see the full
> queue ioctls exposed.

James:

Back in December you wrote a patch to expose the queue ioctls, and sent it
(off-list) to Jens Axboe and to me.  Jens spproved it, but then it
disappeared and was never applied.  Unfortunately I have lost my copy of
it.

If you still have the patch, could you please apply it?  If you don't, I 
could try to re-create it.  Or maybe Jens still has it in his email 
records.  Either way, please let me know.

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Mon, 2007-01-08 at 11:19 -0500, Alan Stern wrote:
> Back in December you wrote a patch to expose the queue ioctls, and sent it
> (off-list) to Jens Axboe and to me.  Jens spproved it, but then it
> disappeared and was never applied.  Unfortunately I have lost my copy of
> it.
> 
> If you still have the patch, could you please apply it?  If you don't, I 
> could try to re-create it.  Or maybe Jens still has it in his email 
> records.  Either way, please let me know.

I have it somewhere ... I was absent from the internet for 2 weeks over
christmas, so I'm still catching up with the backlog.

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Mon, 8 Jan 2007, James Bottomley wrote:

> On Mon, 2007-01-08 at 11:19 -0500, Alan Stern wrote:
> > Back in December you wrote a patch to expose the queue ioctls, and sent it
> > (off-list) to Jens Axboe and to me.  Jens spproved it, but then it
> > disappeared and was never applied.  Unfortunately I have lost my copy of
> > it.
> > 
> > If you still have the patch, could you please apply it?  If you don't, I 
> > could try to re-create it.  Or maybe Jens still has it in his email 
> > records.  Either way, please let me know.
> 
> I have it somewhere ... I was absent from the internet for 2 weeks over
> christmas, so I'm still catching up with the backlog.

Has there been time enough to catch up yet?  I'd still like the see this 
patch applied...  If you can't find it, there's a copy available here:

http://marc.theaimsgroup.com/?l=linux-scsi&m=116828430928154&w=2

While I'm bending your ear, please also consider applying these patches:

http://marc.theaimsgroup.com/?l=linux-scsi&m=116827305914482&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=116827339011208&w=2

Thanks,

Alan Stern

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Jens Axboe]

On Mon, Jan 08 2007, Alan Stern wrote:
> On Wed, 6 Dec 2006, James Bottomley wrote:
> 
> > On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
> > > I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set, 
> > > and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue().  So 
> > > it won't work with sg, which uses character device nodes.
> > 
> > Well, even sg has the queue ... and what we're looking for are the queue
> > parameters.  In block/ioctl.c the bdev is just used for getting the
> > queue parameters (mainly via bdev->bd_disk->queue), so I could see if
> > Jens might be amenable to refactoring the queue ioctls so we can get at
> > them simply with a struct request_queue parameter.
> > 
> > > How about adding BLKSECTGET to the list of commands accepted by 
> > > sg_ioctl()?
> > 
> > That's certainly a possible hack ... although I'd prefer to see the full
> > queue ioctls exposed.
> 
> James:
> 
> Back in December you wrote a patch to expose the queue ioctls, and sent it
> (off-list) to Jens Axboe and to me.  Jens spproved it, but then it
> disappeared and was never applied.  Unfortunately I have lost my copy of
> it.
> 
> If you still have the patch, could you please apply it?  If you don't, I 
> could try to re-create it.  Or maybe Jens still has it in his email 
> records.  Either way, please let me know.

This one?

diff --git a/block/ioctl.c b/block/ioctl.c
index 58aab63..8444d0c 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -135,6 +135,31 @@ static int put_u64(unsigned long arg, u6
 	return put_user(val, (u64 __user *)arg);
 }
 
+static int blk_queue_locked_ioctl(struct request_queue *queue,
+				  unsigned cmd, unsigned long arg)
+{
+	switch (cmd) {
+	case BLKSSZGET: /* get block device hardware sector size */
+		return put_int(arg, queue_hardsect_size(queue));
+	case BLKSECTGET:
+		return put_ushort(arg, queue->max_sectors);
+	}
+	return -ENOIOCTLCMD;
+}
+
+int blk_queue_ioctl(struct request_queue *queue, unsigned cmd,
+		    unsigned long arg)
+{
+	int ret;
+
+	lock_kernel();
+	ret = blk_queue_locked_ioctl(queue, cmd, arg);
+	unlock_kernel();
+
+	return ret;
+}
+EXPORT_SYMBOL(blk_queue_ioctl);
+
 static int blkdev_locked_ioctl(struct file *file, struct block_device *bdev,
 				unsigned cmd, unsigned long arg)
 {
@@ -154,10 +179,6 @@ static int blkdev_locked_ioctl(struct fi
 		return put_int(arg, bdev_read_only(bdev) != 0);
 	case BLKBSZGET: /* get the logical block size (cf. BLKSSZGET) */
 		return put_int(arg, block_size(bdev));
-	case BLKSSZGET: /* get block device hardware sector size */
-		return put_int(arg, bdev_hardsect_size(bdev));
-	case BLKSECTGET:
-		return put_ushort(arg, bdev_get_queue(bdev)->max_sectors);
 	case BLKRASET:
 	case BLKFRASET:
 		if(!capable(CAP_SYS_ADMIN))
@@ -278,6 +299,8 @@ int blkdev_ioctl(struct inode *inode, st
 
 	lock_kernel();
 	ret = blkdev_locked_ioctl(file, bdev, cmd, arg);
+	if (ret == -ENOIOCTLCMD)
+		ret = blk_queue_locked_ioctl(bdev_get_queue(bdev), cmd, arg);
 	unlock_kernel();
 	if (ret != -ENOIOCTLCMD)
 		return ret;
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 81e3bc7..d97244b 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -786,6 +786,11 @@ sg_ioctl(struct inode *inode, struct fil
 				   sdp->disk->disk_name, (int) cmd_in));
 	read_only = (O_RDWR != (filp->f_flags & O_ACCMODE));
 
+	/* block ioctls first */
+	result = blk_queue_ioctl(sdp->device->request_queue, cmd_in, arg);
+	if (result != -ENOIOCTLCMD)
+		return result;
+
 	switch (cmd_in) {
 	case SG_IO:
 		{
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index e1c7286..550b04a 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -754,6 +754,8 @@ extern void blk_queue_prep_rq(request_qu
 extern void blk_queue_merge_bvec(request_queue_t *, merge_bvec_fn *);
 extern void blk_queue_dma_alignment(request_queue_t *, int);
 extern void blk_queue_softirq_done(request_queue_t *, softirq_done_fn *);
+extern int blk_queue_ioctl(struct request_queue *queue, unsigned cmd,
+			   unsigned long arg);
 extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev);
 extern int blk_queue_ordered(request_queue_t *, unsigned, prepare_flush_fn *);
 extern void blk_queue_issue_flush_fn(request_queue_t *, issue_flush_fn *);



-- 
Jens Axboe

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

Alan Stern <stern@rowland.harvard.edu> wrote:

> It turns out that for block device files we don't need to change anything.
> The BLKSECTGET ioctl already does almost exactly what we want:
>
> 	int n;
>
> 	if (ioctl(fd, BLKSECTGET, &n) == 0)
> 		max_transfer_size = n * 512;
>
> So only the legacy sg character-device files need attention, which means 
> that only the part of the patch affecting sg.c is necessary.  The new 
> SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the block 
> layer -- just as SG_[SG]ET_RESERVED_SIZE should be.
>
> How does that sound?

libscg needs a unique ioctl that works for all used filedescriptors that
may be a target for SG_IO.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

James Bottomley <James.Bottomley@SteelEye.com> wrote:

> All CD/DVD burners are block devices, which is the problem set under
> discussion.

Please keep in mind: all CD/DVD burners are SCSI devices.

You cannot write or even retrieve special information without SCSI.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
> Please keep in mind: all CD/DVD burners are SCSI devices.

This is probably semantics, but nowadays, SCSI means SPI (or parallel
SCSI).  I think you're trying to say that they're all devices that obey
the MMC standard?  Which is true, but not really relevant.

> You cannot write or even retrieve special information without SCSI.

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Douglas Gilbert]

James Bottomley wrote:
> On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
>> Please keep in mind: all CD/DVD burners are SCSI devices.
> 
> This is probably semantics, but nowadays, SCSI means SPI (or parallel
> SCSI).  I think you're trying to say that they're all devices that obey
> the MMC standard?  Which is true, but not really relevant.

James,
SPI is dead. Get used to it. SCSI has not meant SPI for
years. We should be in the business of disabusing people
of that idea, not reinforcing it.

If you went to www.t10.org and looked at draft documents
and the reflector you would be lucky to find any documents
or posts about SPI in the last two years.

Doug Gilbert

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Wed, 2006-12-06 at 13:38 -0500, Douglas Gilbert wrote:
> SPI is dead. Get used to it. SCSI has not meant SPI for
> years. We should be in the business of disabusing people
> of that idea, not reinforcing it.

I don't believe I said anything in favour of or against SPI.

I think you'll find the whole point of SAM is separating the command set
from the transport and interconnect.  Saying a device speaks "SCSI" has
no real meaning in that context anymore.  It's commonly taken to mean
SCSI-2 where the whole things was lumped together and SPI centric.

In the SAM context, a modern IDE CD is MMC over an ATAPI or SATAPI
transport. An old SCSI CD is MMC over SPI.  The thing Alan's having
trouble with is MMC over a USB transport.

> If you went to www.t10.org and looked at draft documents
> and the reflector you would be lucky to find any documents
> or posts about SPI in the last two years.

James

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Douglas Gilbert]

James Bottomley wrote:
> On Wed, 2006-12-06 at 13:38 -0500, Douglas Gilbert wrote:
>> SPI is dead. Get used to it. SCSI has not meant SPI for
>> years. We should be in the business of disabusing people
>> of that idea, not reinforcing it.
> 
> I don't believe I said anything in favour of or against SPI.

James,
My objection, and I believe Joerg's objection, is how
people would interpret this statement by you:
"This is probably semantics, but nowadays, SCSI means
SPI (or parallel SCSI)."

One could deduce from that statement, falsely, that the
linux SCSI subsystem was the linux SPI subsystem. Hence
we should mark it as legacy (and stop libata and the new
ATA subsystem from using it).

> I think you'll find the whole point of SAM is separating the command set
> from the transport and interconnect.  Saying a device speaks "SCSI" has
> no real meaning in that context anymore.  It's commonly taken to mean
> SCSI-2 where the whole things was lumped together and SPI centric.

SCSI is a storage architecture, a group of command sets and a
group of transports. The original SCSI transport, now considered
"legacy" (a horribly non-technical word) is SPI.

> In the SAM context, a modern IDE CD is MMC over an ATAPI or SATAPI
> transport. An old SCSI CD is MMC over SPI.  The thing Alan's having
> trouble with is MMC over a USB transport.

Agreed. And USB mass storage would probably be the most
used "SCSI" transport nowadays. Folks can and have written
their own subsystems for handling USB mass storage but
sooner or later they are going to be looking at read
capacity, sense buffers and mode pages. That is why the
SCSI subsystem continues to be relevant.


Doug Gilbert

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

James Bottomley <James.Bottomley@SteelEye.com> wrote:

> On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
> > Please keep in mind: all CD/DVD burners are SCSI devices.
>
> This is probably semantics, but nowadays, SCSI means SPI (or parallel
> SCSI).  I think you're trying to say that they're all devices that obey
> the MMC standard?  Which is true, but not really relevant.
>
> > You cannot write or even retrieve special information without SCSI.

I am not sure if you did ever have a look at t10.org.

SCSI is a widely used protocol that is supported over many different transports.
SPI is as dead as PATA and note that SAS controllers will transparently handle
even SATA devices.

SCSI supports many more devices than MMC and SCSI runs on many different 
transports. 

The SCSI protocol layer has been separated from the transport layer in the 
early 1990s. Please do not try to make asumptions based on outdated information.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Douglas Gilbert]

James Bottomley wrote:
> On Wed, 2006-12-06 at 11:32 -0500, Alan Stern wrote:
>>> But how did he get the file descriptor?  He opened a device name, which
>>> could have been used to get the sysfs file.
>> The device name was probably something like /dev/sg0.  This doesn't easily
>> permit one to find the corresponding sysfs filename for the real
>> underlying device, although it can be done with difficulty.  (That's why I
>> used the excessively-ornate sysfs pathname in the Bugzilla entry.)  It
>> certainly wouldn't be as easy as using an ioctl.
>>
>> It wouldn't be as uniform either.  The search through sysfs would have to 
>> be different depending on whether the device name was /dev/sr0 or 
>> /dev/sg0.
> 
> Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've
> tried to get some for some of my older boxes.  Most of them nowadays are
> IDE attachments, which don't have a /dev/sg node.  So /dev/sg is really
> the legacy mode for burning.  The correct way to do it today is to use
> the actual device name ... then you don't have to worry about what the
> transport is any more.

All CD and DVD drive these days use SCSI. That is
SCSI command sets: MMC and SPC. Very few use the
SCSI Parallel Interface (SPI). An increasing number
will be using S-ATAPI and they could be seen by
the OS via "SCSI" transports: FC and SAS (+ SATA).

>>>> Is the patch below acceptable?
>>> Really, no.  The parameter you're fishing for is a block parameter, not
>>> a SCSI parameter ... it should really be a block ioctl if we have to
>>> have an ioctl at all.
>> I could easily enough rewrite the patch to put the ioctl somewhere else
>> (although I'm not quite sure exactly where would be best).  But do
>> non-block devices have request queues?  What about the points that Doug
>> raised:
> 
> All CD/DVD burners are block devices, which is the problem set under
> discussion.

CD/DVD burners are block device for read operations
only. When they are "burning" they are not block
devices in the normal sense.

So if this was classic Unix a block device node would
be used for reading and a raw device node for writing.
Just like .... I'm wasting keystrokes.

>> On Tue, 5 Dec 2006, Douglas Gilbert wrote:
>>
>>> Apart from sensibly yielding the max size in bytes, your patch
>>> has the added benefit of allowing non-block devices (e.g. tape,
>>> processor and enclosure services) to find out what limit the
>>> OS/host has placed on each command's maximum transfer size.
> 
> They all possess block queues, yes, so we should really allow access to
> the block ioctls for them.
> 
>>> If you manage to get that ioctl in, then ungrateful people
>>> will ask for the corresponding "set" operation as well.
>>>
>>>
>>> To illustrate the /sys mess look at naming of the sysfs approach
>>> to this problem. For example:
>>>   /sys/block/sde/queue/max_sectors_kb
>>>     - it is not only a "block" property
>>>     - sde is an "end device" and suggests information from that
>>>       device's Block Limits VPD page, actually it is a limit
>>>       imposed by the OS and the host used to access that device
>>>     - what has "queue" got to do with it?
>>>     - "max_sectors_kb" should have units of bytes
>> In addition to all of these points, there remains the peculiar location of 
>> the SG_ ioctls.  They are implemented it two places in the kernel: 
>> block/scsi_ioctl.c and drivers/scsi/sg.c.  And the two implementations of 
>> e.g. SG_SET_RESERVED_SIZE don't even do the same thing!
> 
> I have no idea why the block layer even implements
> SG_SET_RESERVED_SIZE ... I suspect it was some legacy application
> compatibility problem, so it probably can be eliminated.

It was put there to trick cdrecord!

Doug Gilbert

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Douglas Gilbert]

Alan Stern wrote:
> I decided to do this by email instead of bugzilla so that it would be 
> visible to everyone on the linux-scsi mailing list.
> 
> Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
> 
> To recap: Joerg Schilling needs to be able to retrieve the max_sectors 
> value for a SCSI device's request queue.  Doing it via sysfs is rather 
> clumsy, especially when only a file descriptor is available and not the 
> device name.  He has asked for an ioctl interface to provide the 
> information.
> 
> Is the patch below acceptable?

Alan,
I just spent an hour thinking about how to data mine through
that dreadful mess that /sys has become as I try to add
transport information to lsscsi.

And then this post made my day. Fancy that, adding a new
ioctl!! I hope the ioctl police aren't watching :-)

Apart from sensibly yielding the max size in bytes, your patch
has the added benefit of allowing non-block devices (e.g. tape,
processor and enclosure services) to find out what limit the
OS/host has placed on each command's maximum transfer size.

If you manage to get that ioctl in, then ungrateful people
will ask for the corresponding "set" operation as well.


To illustrate the /sys mess look at naming of the sysfs approach
to this problem. For example:
  /sys/block/sde/queue/max_sectors_kb
    - it is not only a "block" property
    - sde is an "end device" and suggests information from that
      device's Block Limits VPD page, actually it is a limit
      imposed by the OS and the host used to access that device
    - what has "queue" got to do with it?
    - "max_sectors_kb" should have units of bytes
And /sys has the horrible side effect of enshrining a badly
conceived design in a user interface (and SAS comes to mind).


Best of luck
Doug Gilbert


BTW Joerg: SG_SET_RESERVED_SIZE simply makes it extremely
unlikely that the sg driver will not be able to fetch
enough memory from the kernel to move data associated with
a SCSI command. The block layer SG_IO just fudges that.
While a major concern in lk 2.0, memory starvation is typically
not a major concern in lk 2.6 assuming modern hardware.
The sg driver's reserved buffer has other uses as
FUJITA Tomonori pointed out yesterday on the linux-scsi list.

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

Douglas Gilbert <dgilbert@interlog.com> wrote:

> BTW Joerg: SG_SET_RESERVED_SIZE simply makes it extremely
> unlikely that the sg driver will not be able to fetch
> enough memory from the kernel to move data associated with
> a SCSI command. The block layer SG_IO just fudges that.
> While a major concern in lk 2.0, memory starvation is typically
> not a major concern in lk 2.6 assuming modern hardware.
> The sg driver's reserved buffer has other uses as
> FUJITA Tomonori pointed out yesterday on the linux-scsi list.

If it is documented, no problem. The information I had said that 
SG_SET_RESERVED_SIZE would be limited in case that the HW does not allow 
bigger sizes.

Let us try out whether the proposed interface works as expected.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

Alan Stern <stern@rowland.harvard.edu> wrote:

> I decided to do this by email instead of bugzilla so that it would be 
> visible to everyone on the linux-scsi mailing list.

Thank you, this is a more convenient way of having a discussion.

> Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
>
> To recap: Joerg Schilling needs to be able to retrieve the max_sectors 
> value for a SCSI device's request queue.  Doing it via sysfs is rather 
> clumsy, especially when only a file descriptor is available and not the 
> device name.  He has asked for an ioctl interface to provide the 
> information.
>
> Is the patch below acceptable?

If the number in "sectors" is not a value in sectors but a value in 512 byte 
units, it looks OK.

Is this value correct for all "host adaptors"?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

Alan Stern <stern@rowland.harvard.edu> wrote:

> I decided to do this by email instead of bugzilla so that it would be 
> visible to everyone on the linux-scsi mailing list.
>
> Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026

I just put out preliminary support for this ioctl.

Please check:

ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a23-pre.tar.bz2

and try out whether the problems are now gone.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

[Bug 7026] CD/DVD burning with USB writer doesn't work

[Joerg Schilling]

Hi,

it's 2 monts that we did discuss this problem.
Has the solution integrated into the Linux kernel?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Alan Stern]

On Fri, 9 Feb 2007, Joerg Schilling wrote:

> Hi,
> 
> it's 2 monts that we did discuss this problem.
> Has the solution integrated into the Linux kernel?
> 
> Jörg

Not yet.  Despited repeated inquiries, I still haven't heard anything back 
from James regarding the patch that he wrote.

James, if you prefer I can send that patch to Andrew Morton.  Would that 
be easier for you?

Alan Stern

-
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

Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[James Bottomley]

On Fri, 2007-02-09 at 12:57 -0500, Alan Stern wrote:
> > it's 2 monts that we did discuss this problem.
> > Has the solution integrated into the Linux kernel?
> > 
> > Jörg
> 
> Not yet.  Despited repeated inquiries, I still haven't heard anything back 
> from James regarding the patch that he wrote.
> 
> James, if you prefer I can send that patch to Andrew Morton.  Would that 
> be easier for you?

Actually, the patch I wrote was a block patch, so it goes through Jens'
tree.

I know he had it a while ago ... but I'm afraid there's a bit of a
fundamental breakdown in the usual open source process because the
author (unfortunately me) should be tracking it, and I'm not really ...
if it were my tree, I would probably have just slipped it in to prevent
my forgetting about it, but it isn't.

I added Jens to the cc list, so he can probably tell us what happened to
it.

James


-
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