[PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

[PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

[Douglas Gilbert]

[-- Attachment #1: Type: text/plain, Size: 333 bytes --]

For disks both the SCSI_IOCTL_GET_IDLUN and
SCSI_IOCTL_GET_BUS_NUMBER ioctls return the value
0 (type: int) in all cases. The attachment removes
the dummy definitions of these ioctls in
driver/block/scsi_ioctl.c so they fall through
to the scsi mid level which correctly implements
them (at least in terms of lk 2.4).

Doug Gilbert


[-- Attachment #2: scsi_ioctl_blk2551.diff --]
[-- Type: text/plain, Size: 802 bytes --]

--- linux/drivers/block/scsi_ioctl.c	2002-11-29 09:27:35.000000000 +1100
+++ linux/drivers/block/scsi_ioctl.c2551xidlun	2002-12-12 18:19:23.000000000 +1100
@@ -73,16 +73,6 @@
 	return put_user(sg_version_num, p);
 }
 
-static int scsi_get_idlun(request_queue_t *q, int *p)
-{
-	return put_user(0, p);
-}
-
-static int scsi_get_bus(request_queue_t *q, int *p)
-{
-	return put_user(0, p);
-}
-
 static int sg_get_timeout(request_queue_t *q)
 {
 	return q->sg_timeout;
@@ -413,10 +403,6 @@
 		 */
 		case SG_GET_VERSION_NUM:
 			return sg_get_version((int *) arg);
-		case SCSI_IOCTL_GET_IDLUN:
-			return scsi_get_idlun(q, (int *) arg);
-		case SCSI_IOCTL_GET_BUS_NUMBER:
-			return scsi_get_bus(q, (int *) arg);
 		case SG_SET_TIMEOUT:
 			return sg_set_timeout(q, (int *) arg);
 		case SG_GET_TIMEOUT:

Re: [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

[James Bottomley]

dougg@torque.net said:
> For disks both the SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER
> ioctls return the value 0 (type: int) in all cases. The attachment
> removes the dummy definitions of these ioctls in driver/block/
> scsi_ioctl.c so they fall through to the scsi mid level which
> correctly implements them (at least in terms of lk 2.4). 

I'm not sure this is the correct thing to do.  These ioctls may be there 
because cdrecord is using them.  In the new scheme, you can record a CD 
without ever troubling the scsi mid-layer, so if cdrecord wants them, they 
have to be provided in some fashion without relying on a fall through.

I've copied Jens on this mail, since he's the one that knows this stuff and 
should be able to confirm or deny this suspicion.  Jens?

James

Re: [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

[Jens Axboe]

On Thu, Dec 12 2002, James Bottomley wrote:
> dougg@torque.net said:
> > For disks both the SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER
> > ioctls return the value 0 (type: int) in all cases. The attachment
> > removes the dummy definitions of these ioctls in driver/block/
> > scsi_ioctl.c so they fall through to the scsi mid level which
> > correctly implements them (at least in terms of lk 2.4). 
> 
> I'm not sure this is the correct thing to do.  These ioctls may be there 
> because cdrecord is using them.  In the new scheme, you can record a CD 
> without ever troubling the scsi mid-layer, so if cdrecord wants them, they 
> have to be provided in some fashion without relying on a fall through.
> 
> I've copied Jens on this mail, since he's the one that knows this stuff and 
> should be able to confirm or deny this suspicion.  Jens?

Hmm, I _may_ be wrong but I think the main reason for GET_IDLUN and
GET_BUS_NUMBER in the generic block layer is to stop them from failing
in libscg and thus fooling it into believing we are scsi. You would need
to check libscg/scsi-linux-sg.c to be sure.

For one thing, we need to maintain the behaviour we have now of _not_
failing them for ata devices. If you want to pass them down to SCSI as
well and get the right id/lun and bus, fine, but don't break the ata
one.

-- 
Jens Axboe

Re: [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

[Christoph Hellwig]

On Thu, Dec 12, 2002 at 06:42:41PM +0100, Jens Axboe wrote:
> Hmm, I _may_ be wrong but I think the main reason for GET_IDLUN and
> GET_BUS_NUMBER in the generic block layer is to stop them from failing
> in libscg and thus fooling it into believing we are scsi. You would need
> to check libscg/scsi-linux-sg.c to be sure.
> 
> For one thing, we need to maintain the behaviour we have now of _not_
> failing them for ata devices. If you want to pass them down to SCSI as
> well and get the right id/lun and bus, fine, but don't break the ata
> one.

I disagree.  USerspace needs changes to support SG_IO on block device anyway
so we should do it properly.  There is no harm in changing interface during
2.5.  IMHO most of the silly sg ioctl stubs in drivers/block/scsi_ioctl.c
should just die.

Re: [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

[Jens Axboe]

On Thu, Dec 12 2002, Christoph Hellwig wrote:
> On Thu, Dec 12, 2002 at 06:42:41PM +0100, Jens Axboe wrote:
> > Hmm, I _may_ be wrong but I think the main reason for GET_IDLUN and
> > GET_BUS_NUMBER in the generic block layer is to stop them from failing
> > in libscg and thus fooling it into believing we are scsi. You would need
> > to check libscg/scsi-linux-sg.c to be sure.
> > 
> > For one thing, we need to maintain the behaviour we have now of _not_
> > failing them for ata devices. If you want to pass them down to SCSI as
> > well and get the right id/lun and bus, fine, but don't break the ata
> > one.
> 
> I disagree.  USerspace needs changes to support SG_IO on block device anyway
> so we should do it properly.  There is no harm in changing interface during

How do you figure? Some of them probably, but most should just work
(provided they use SG_IO ioctl, of course).

> 2.5.  IMHO most of the silly sg ioctl stubs in drivers/block/scsi_ioctl.c
> should just die.

Feel free, I don't have time to do it right now.

-- 
Jens Axboe

Re: [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

[Douglas Gilbert]

Jens Axboe wrote:
> On Thu, Dec 12 2002, James Bottomley wrote:
> 
>>dougg@torque.net said:
>>
>>>For disks both the SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER
>>>ioctls return the value 0 (type: int) in all cases. The attachment
>>>removes the dummy definitions of these ioctls in driver/block/
>>>scsi_ioctl.c so they fall through to the scsi mid level which
>>>correctly implements them (at least in terms of lk 2.4). 
>>
>>I'm not sure this is the correct thing to do.  These ioctls may be there 
>>because cdrecord is using them.  In the new scheme, you can record a CD 
>>without ever troubling the scsi mid-layer, so if cdrecord wants them, they 
>>have to be provided in some fashion without relying on a fall through.
>>
>>I've copied Jens on this mail, since he's the one that knows this stuff and 
>>should be able to confirm or deny this suspicion.  Jens?
> 
> 
> Hmm, I _may_ be wrong but I think the main reason for GET_IDLUN and
> GET_BUS_NUMBER in the generic block layer is to stop them from failing
> in libscg and thus fooling it into believing we are scsi. You would need
> to check libscg/scsi-linux-sg.c to be sure.

One reason libscg/scsi-linux-sg.c (cdrecord) would use
them is to differentiate between multiple "pseudo" scsi
devices when it is doing a scd to sg mapping. [This is the area
where I saw my sg_utils break.]

So defining them and always yielding 0 is going to confuse
it when there are two or more devices (e.g. 2 cd writers).

cdrecord uses the <host, target_id, lun> triple to enumerate
cd writers (rather than linux's <host, channel, target_id, lun>).
It is not clear to me how trying to define a correct
SCSI_IOCTL_GET_IDLUN ioctl in the block level can cope with
the strange combination of one scsi cdwriter and one atapi
cdrwiter in the same box. [That is, will they have distinct
host numbers?]

There are also applications like cdparanoia to consider.

> For one thing, we need to maintain the behaviour we have now of _not_
> failing them for ata devices. If you want to pass them down to SCSI as
> well and get the right id/lun and bus, fine, but don't break the ata
> one.

There is also the meaning of these ioctls in lk 2.4
to consider.

How to define these ioctls properly for scsi block devices
and return "0" for other types of block devices??
Well sd and sr could be patched to route these two ioctls
to the scsi mid level and let other ioctls be diverted
through drivers/block/scsi_ioctl.c . Is that ugly enough :-)



BTW SCSI_IOCTL_GET_IDLUN ioctl in lk 2.4 and earlier yields
2 integer values (not 1).

Doug Gilbert