2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

PATCH In review Douglas Gilbert 4 participants 6 messages Dec 12, 2002

Subsystems (2)

SCSI Block layer

lore

Share & tools

lore

Douglas Gilbert

author

2002-12-12 07:41 UTC #0 lore raw

PATCH 1/1 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER

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

drivers/block/scsi_ioctl.c2551xidlun renamed from drivers/block/scsi_ioctl.c +0 ~~-14~~

@@ -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:

James Bottomley

2002-12-12 14:27 UTC #1 lore raw

Quoted 5 lines · [email protected] 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

Jens Axboe

2002-12-12 17:42 UTC #2 lore raw

Quoted 7 lines · James Bottomley

Quoted 5 lines · [email protected] 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).

Quoted 7 lines

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.

Signature · 1 line

Jens Axboe

Christoph Hellwig

2002-12-12 20:39 UTC #3 lore raw

Quoted 9 lines · Jens Axboe

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.

Jens Axboe

2002-12-12 20:40 UTC #4 lore raw

Quoted 6 lines · Christoph Hellwig

Quoted 5 lines · Jens Axboe
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.

Quoted 7 lines

Quoted 4 lines
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).

Quoted 2 lines

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.

Signature · 1 line

Jens Axboe

Douglas Gilbert

author

2002-12-12 22:40 UTC #5 lore raw

In reply to Jens Axboe

Quoted 12 lines · Jens Axboe

Quoted 10 lines · James Bottomley
Quoted 5 lines · [email protected] 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.

Quoted 7 lines

Quoted 1 line
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.

Quoted 4 lines

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