[RFC] Deprecate, modify, or do nothing to SCSI_IOCTL_GET_IDLUN

[RFC] Deprecate, modify, or do nothing to SCSI_IOCTL_GET_IDLUN

[Seymour, Shane M]

I'd like to ask if SCSI_IOCTL_GET_IDLUN should be deprecated? This is in response to [Bug 88591] SCSI_IOCTL_GET_IDLUN only returns 8 bits for the SCSI Target value of which has been seen on the mailing list.

It only returns one byte of id, lun, channel, and host number but we have SG_GET_SCSI_ID which fills a structure with a separate int for each of those 4 values.

There's two choices in terms of deprecation. The first is immediately deprecating it by moving it in scsi_ioctl() the other deprecated ioctls so it no longer works ad issues a warning or the second keep it working for the time being and add the following before it returns 0 from that function:

	if (printk_ratelimit())
		printk (KERN_WARNING "program %s is using a deprecated SCSI "
			"ioctl SCSI_IOCTL_GET_IDLUN, please convert it to use SG_GET_SCSI_ID \n",
			 current->comm);

After some suitable period of time move it to the other deprecated ioctls scsi_ioctl() where it will stop working and print the same deprecation message as other deprecated ioctls. 

Alternative 3 is to look at the values being compacted into the 4 bytes and if any of id, lun, channel or host overflow their single byte compacted value return -EOVERFLOW if any do and then provide a hint to the caller that they should be using SG_GET_SCSI_ID instead. That would instead change the return 0 in scsi_ioctl() for SCSI_IOCTL_GET_IDLUN to be something like:

		if ((sdev->id > 0xff) || (sdev->lun > 0xff) || (sdev->channel > 0xff)
			|| (sdev->host->host_no > 0xff)) {
			printk(KERN_WARNING "program %s - overflow in ioctl SCSI_IOCTL_GET_IDLUN, "
				"please convert it to use SG_GET_SCSI_ID\n", current->comm);
			return -EOVERFLOW;
		} else {
			return 0;
		}

It allows backwards compatibility (it will still overflow in exactly the same way) and for a lot of systems it will still work for most uses but provides an indication that something has gone wrong and the data returned shouldn't be relied upon to be valid when any of the information has overflowed what it's been stored in. 

Alternative 4 is do nothing people should understand the limitations of what ioctls they use (they have the source) and TLDP documents SG_GET_SCSI_ID so anyone using SCSI_IOCTL_GET_IDLUN should be aware of the fact that there are alternative SG ioctls with wider values for id, lun, channel, and host number.

There may be other possibilities that I've overlooked. After some consensus about what should be done I'm happy to put together a patch for review.