[PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Patrick Mansfield]

Patch against current scsi-misc-2.5 tree.

Remove the scsi EVPD code.

Set the sysfs name to the form "SCSI scsi-type".

--- 1.79/drivers/scsi/scsi_scan.c	Wed Apr 23 03:22:53 2003
+++ edited/drivers/scsi/scsi_scan.c	Thu Apr 24 16:55:44 2003
@@ -506,481 +506,6 @@
 }
 
 /**
- * scsi_get_evpd_page - get a list of supported vpd pages
- * @sdev:	Scsi_Device to send an INQUIRY VPD
- * @sreq:	Scsi_Request associated with @sdev
- *
- * Description:
- *     Get SCSI INQUIRY Vital Product Data page 0 - a list of supported
- *     VPD pages.
- *
- * Return:
- *     A pointer to data containing the results on success, else NULL.
- **/
-unsigned char *scsi_get_evpd_page(Scsi_Device *sdev, Scsi_Request *sreq)
-{
-	unsigned char *evpd_page;
-	unsigned char scsi_cmd[MAX_COMMAND_SIZE];
-	int max_lgth = 255;
-
-retry:
-	evpd_page = kmalloc(max_lgth, GFP_ATOMIC |
-			      (sdev->host->unchecked_isa_dma) ?
-			      GFP_DMA : 0);
-	if (!evpd_page) {
-		printk(KERN_WARNING "scsi scan: Allocation failure identifying"
-		       " host %d channel %d id %d lun %d, device might be"
-		       " improperly identified.\n", sdev->host->host_no,
-		       sdev->channel, sdev->id, sdev->lun);
-		return NULL;
-	}
-
-	memset(scsi_cmd, 0, MAX_COMMAND_SIZE);
-	scsi_cmd[0] = INQUIRY;
-	scsi_cmd[1] = 0x01;
-	scsi_cmd[4] = max_lgth;
-	sreq->sr_cmd_len = 0;
-	sreq->sr_sense_buffer[0] = 0;
-	sreq->sr_sense_buffer[2] = 0;
-	sreq->sr_data_direction = SCSI_DATA_READ;
-	scsi_wait_req(sreq, (void *) scsi_cmd, (void *) evpd_page,
-			max_lgth, SCSI_TIMEOUT+4*HZ, 3);
-
-	if (sreq->sr_result) {
-		kfree(evpd_page);
-		return NULL;
-	}
-
-	/*
-	 * check to see if response was truncated
-	 */
-	if (evpd_page[3] > max_lgth) {
-		max_lgth = evpd_page[3] + 4;
-		kfree(evpd_page);
-		goto retry;
-	}
-
-	/*
-	 * Some ill behaved devices return the standard inquiry here
-	 * rather than the evpd data, snoop the data to verify.
-	 */
-	if (evpd_page[3] > 16) {
-		/*
-		 * If the vendor id appears in the evpd page assume the
-		 * page is invalid.
-		 */
-		if (!strncmp(&evpd_page[8], sdev->vendor, 8)) {
-			kfree(evpd_page);
-			return NULL;
-		}
-	}
-	return evpd_page;
-}
-
-
-/*
- * INQUIRY VPD page 0x83 identifier descriptor related values. Reference the
- * SCSI Primary Commands specification for details.
- *
- * XXX The following defines should be in scsi.h
- */
-
-/*
- * id type values of id descriptors. These are assumed to fit in 4 bits,
- * else the code using hex_str[id_type] needs modification.
- */
-#define SCSI_ID_VENDOR_SPECIFIC	0
-#define SCSI_ID_T10_VENDOR	1
-#define SCSI_ID_EUI_64		2
-#define SCSI_ID_NAA		3
-
-/*
- * Supported NAA values. These fit in 4 bits, so the don't care value
- * cannot conflict with real values.
- *
- */
-#define	SCSI_ID_NAA_DONT_CARE		0xff
-#define	SCSI_ID_NAA_IEEE_REG		5
-#define	SCSI_ID_NAA_IEEE_REG_EXTENDED	6
-
-/*
- * Supported Code Set values.
- */
-#define	SCSI_ID_BINARY	1
-#define	SCSI_ID_ASCII	2
-
-/*
- * Use a priority based list of id, naa, and binary/ascii for the
- * identifier descriptor in VPD page 0x83.
- *
- * Brute force search for a match starting with the first value in
- * id_search_list. This is not a performance issue, since there
- * is normally one or some small number of descriptors.
- */
-struct scsi_id_search_values {
-	int	id_type;
-	int	naa_type;
-	int	code_set;
-};
-
-static const struct scsi_id_search_values id_search_list[] = {
-	{ SCSI_ID_NAA,	SCSI_ID_NAA_IEEE_REG_EXTENDED,	SCSI_ID_BINARY },
-	{ SCSI_ID_NAA,	SCSI_ID_NAA_IEEE_REG_EXTENDED,	SCSI_ID_ASCII },
-	{ SCSI_ID_NAA,	SCSI_ID_NAA_IEEE_REG,	SCSI_ID_BINARY },
-	{ SCSI_ID_NAA,	SCSI_ID_NAA_IEEE_REG,	SCSI_ID_ASCII },
-	/*
-	 * Devices already exist using NAA values that are now marked
-	 * reserved. These should not conflict with other values, or it is
-	 * a bug in the device. As long as we find the IEEE extended one
-	 * first, we really don't care what other ones are used. Using
-	 * don't care here means that a device that returns multiple
-	 * non-IEEE descriptors in a random order will get different
-	 * names.
-	 */
-	{ SCSI_ID_NAA,	SCSI_ID_NAA_DONT_CARE,	SCSI_ID_BINARY },
-	{ SCSI_ID_NAA,	SCSI_ID_NAA_DONT_CARE,	SCSI_ID_ASCII },
-	{ SCSI_ID_EUI_64,	SCSI_ID_NAA_DONT_CARE,	SCSI_ID_BINARY },
-	{ SCSI_ID_EUI_64,	SCSI_ID_NAA_DONT_CARE,	SCSI_ID_ASCII },
-	{ SCSI_ID_T10_VENDOR,	SCSI_ID_NAA_DONT_CARE,	SCSI_ID_BINARY },
-	{ SCSI_ID_T10_VENDOR,	SCSI_ID_NAA_DONT_CARE,	SCSI_ID_ASCII },
-	{ SCSI_ID_VENDOR_SPECIFIC,	SCSI_ID_NAA_DONT_CARE,	SCSI_ID_BINARY },
-	{ SCSI_ID_VENDOR_SPECIFIC,	SCSI_ID_NAA_DONT_CARE,	SCSI_ID_ASCII },
-};
-
-/**
- * scsi_check_fill_deviceid - check the id and if OK fill it
- * @sdev:	device to use for error messages
- * @id_page:	id descriptor for INQUIRY VPD DEVICE ID, page 0x83
- * @name:	store the id in name (of size DEVICE_NAME_SIZE > 26)
- * @id_search:	store if the id_page matches these values
- *
- * Description:
- *     Check if @id_page matches the @id_search, if so store an id (uid)
- *     into name, that is all zero on entrance.
- *
- * Return:
- *     0: Success
- *     1: No match
- **/
-static int scsi_check_fill_deviceid(Scsi_Device *sdev, char *id_page,
-	char *name, const struct scsi_id_search_values *id_search)
-{
-	static const char hex_str[]="0123456789abcdef";
-	int i, j;
-
-	/*
-	 * ASSOCIATION must be with the device (value 0)
-	 */
-	if ((id_page[1] & 0x30) != 0)
-		return 1;
-
-	if ((id_page[1] & 0x0f) != id_search->id_type)
-		return 1;
-	/*
-	 * Possibly check NAA sub-type.
-	 */
-	if ((id_search->naa_type != SCSI_ID_NAA_DONT_CARE) &&
-	    (id_search->naa_type != (id_page[4] & 0xf0) >> 4)) {
-		return 1;
-	}
-
-	/*
-	 * Check for matching code set - ASCII or BINARY.
-	 */
-	if ((id_page[0] & 0x0f) != id_search->code_set)
-		return 1;
-
-	/*
-	 * All OK - store ID
-	 */
-	name[0] = hex_str[id_search->id_type];
-
-	/*
-	 * Prepend the vendor and model before the id, since the id
-	 * might not be unique across all vendors and models.
-	 * The same code is used below, with a different size.
-	 */
-	if (id_search->id_type == SCSI_ID_VENDOR_SPECIFIC) {
-		strncat(name, sdev->vendor, 8);
-		strncat(name, sdev->model, 16);
-	}
-
-	i = 4;
-	j = strlen(name);
-	if ((id_page[0] & 0x0f) == SCSI_ID_ASCII) {
-		/*
-		 * ASCII descriptor.
-		 */
-		while (i < 4 + id_page[3] && j < DEVICE_NAME_SIZE-1)
-			name[j++] = id_page[i++];
-	} else {
-		/*
-		 * Binary descriptor, convert to ASCII, using two bytes of
-		 * ASCII for each byte in the id_page.
-		 */
-		while (i < 4 + id_page[3] && j < DEVICE_NAME_SIZE-2) {
-			name[j++] = hex_str[(id_page[i] & 0xf0) >> 4];
-			name[j++] = hex_str[id_page[i] & 0x0f];
-			i++;
-		}
-	}
-	return 0;
-}
-
-/**
- * scsi_get_deviceid - get a device id using INQUIRY VPD page 0x83
- * @sdev:	get the identifer of this device
- * @sreq:	Scsi_Requeset associated with @sdev
- *
- * Description:
- *     Try to get an id (serial number) for device @sdev using a SCSI
- *     Vital Product Data page 0x83 (device id).
- *
- * Return:
- *     0: Failure
- *     1: Success
- **/
-static int scsi_get_deviceid(Scsi_Device *sdev, Scsi_Request *sreq)
-{
-	unsigned char *id_page;
-	unsigned char scsi_cmd[MAX_COMMAND_SIZE];
-	int id_idx, scnt, ret;
-	int max_lgth = 255;
-
-retry:
-	id_page = kmalloc(max_lgth, GFP_ATOMIC |
-			      (sdev->host->unchecked_isa_dma) ?
-			      GFP_DMA : 0);
-	if (!id_page) {
-		printk(KERN_WARNING "scsi scan: Allocation failure identifying"
-		       " host %d channel %d id %d lun %d, device might be"
-		       " improperly identified.\n", sdev->host->host_no,
-		       sdev->channel, sdev->id, sdev->lun);
-		return 0;
-	}
-
-	memset(scsi_cmd, 0, MAX_COMMAND_SIZE);
-	scsi_cmd[0] = INQUIRY;
-	scsi_cmd[1] = 0x01;
-	scsi_cmd[2] = 0x83;
-	scsi_cmd[4] = max_lgth;
-	sreq->sr_cmd_len = 0;
-	sreq->sr_sense_buffer[0] = 0;
-	sreq->sr_sense_buffer[2] = 0;
-	sreq->sr_data_direction = SCSI_DATA_READ;
-	scsi_wait_req(sreq, (void *) scsi_cmd, (void *) id_page,
-			max_lgth, SCSI_TIMEOUT+4*HZ, 3);
-	if (sreq->sr_result) {
-		ret = 0;
-		goto leave;
-	}
-
-	/*
-	 * check to see if response was truncated
-	 */
-	if (id_page[3] > max_lgth) {
-		max_lgth = id_page[3] + 4;
-		kfree(id_page);
-		goto retry;
-	}
-
-	/*
-	 * Search for a match in the prioritized id_search_list.
-	 */
-	for (id_idx = 0; id_idx < ARRAY_SIZE(id_search_list); id_idx++) {
-		/*
-		 * Examine each descriptor returned. There is normally only
-		 * one or a small number of descriptors.
-		 */
-		for (scnt = 4; scnt <= id_page[3] + 3;
-			scnt += id_page[scnt + 3] + 4) {
-			if ((scsi_check_fill_deviceid(sdev, &id_page[scnt],
-			     sdev->sdev_driverfs_dev.name,
-			     &id_search_list[id_idx])) == 0) {
-				SCSI_LOG_SCAN_BUS(4, printk(KERN_INFO
-				  "scsi scan: host %d channel %d id %d lun %d"
-				  " used id desc %d/%d/%d\n",
-				  sdev->host->host_no, sdev->channel,
-				  sdev->id, sdev->lun,
-				  id_search_list[id_idx].id_type,
-				  id_search_list[id_idx].naa_type,
-				  id_search_list[id_idx].code_set));
-				ret = 1;
-				goto leave;
-			} else {
-				SCSI_LOG_SCAN_BUS(4, printk(KERN_INFO
-				  "scsi scan: host %d channel %d id %d lun %d"
-				  " no match/error id desc %d/%d/%d\n",
-				  sdev->host->host_no, sdev->channel,
-				  sdev->id, sdev->lun,
-				  id_search_list[id_idx].id_type,
-				  id_search_list[id_idx].naa_type,
-				  id_search_list[id_idx].code_set));
-			}
-			/*
-			 * scsi_check_fill_deviceid can fill the first
-			 * byte of name with a non-zero value, reset it.
-			 */
-			sdev->sdev_driverfs_dev.name[0] = '\0';
-		}
-	}
-	ret = 0;
-
-  leave:
-	kfree(id_page);
-	return ret;
-}
-
-/**
- * scsi_get_serialnumber - get a serial number using INQUIRY page 0x80
- * @sdev:	get the serial number of this device
- * @sreq:	Scsi_Requeset associated with @sdev
- *
- * Description:
- *     Send a SCSI INQUIRY page 0x80 to @sdev to get a serial number.
- *
- * Return:
- *     0: Failure
- *     1: Success
- **/
-int scsi_get_serialnumber(Scsi_Device *sdev, Scsi_Request *sreq)
-{
-	unsigned char *serialnumber_page;
-	unsigned char scsi_cmd[MAX_COMMAND_SIZE];
-	const int max_lgth = 255;
-	int len;
-
-	serialnumber_page = kmalloc(max_lgth, GFP_ATOMIC |
-			      (sdev->host->unchecked_isa_dma) ? GFP_DMA : 0);
-	if (!serialnumber_page) {
-		printk(KERN_WARNING "scsi scan: Allocation failure identifying"
-		       " host %d channel %d id %d lun %d, device might be"
-		       " improperly identified.\n", sdev->host->host_no,
-		       sdev->channel, sdev->id, sdev->lun);
-		return 0;
-	}
-
-	memset(scsi_cmd, 0, MAX_COMMAND_SIZE);
-	scsi_cmd[0] = INQUIRY;
-	scsi_cmd[1] = 0x01;
-	scsi_cmd[2] = 0x80;
-	scsi_cmd[4] = max_lgth;
-	sreq->sr_cmd_len = 0;
-	sreq->sr_sense_buffer[0] = 0;
-	sreq->sr_sense_buffer[2] = 0;
-	sreq->sr_data_direction = SCSI_DATA_READ;
-	scsi_wait_req(sreq, (void *) scsi_cmd, (void *) serialnumber_page,
-			max_lgth, SCSI_TIMEOUT+4*HZ, 3);
-
-	if (sreq->sr_result)
-		goto leave;
-
-	/*
-	 * a check to see if response was truncated is superfluous,
-	 * since serialnumber_page[3] cannot be larger than 255
-	 */
-
-	sdev->sdev_driverfs_dev.name[0] = SCSI_UID_SER_NUM;
-	strncat(sdev->sdev_driverfs_dev.name, sdev->vendor, 8);
-	strncat(sdev->sdev_driverfs_dev.name, sdev->model, 16);
-	len = serialnumber_page[3];
-	if (len > DEVICE_NAME_SIZE-26)
-		len = DEVICE_NAME_SIZE-26;
-	strncat(sdev->sdev_driverfs_dev.name, &serialnumber_page[4], len);
-	kfree(serialnumber_page);
-	return 1;
- leave:
-	memset(sdev->sdev_driverfs_dev.name, 0, DEVICE_NAME_SIZE);
-	kfree(serialnumber_page);
-	return 0;
-}
-
-/**
- * scsi_get_default_name - get a default name
- * @sdev:	get a default name for this device
- *
- * Description:
- *     Set the name of @sdev (of size DEVICE_NAME_SIZE > 29) to the
- *     concatenation of the vendor, model, and revision found in @sdev.
- *
- * Return:
- *     1: Success
- **/
-int scsi_get_default_name(Scsi_Device *sdev)
-{
-	sdev->sdev_driverfs_dev.name[0] = SCSI_UID_UNKNOWN;
-	strncpy(&sdev->sdev_driverfs_dev.name[1], sdev->vendor, 8);
-	strncat(sdev->sdev_driverfs_dev.name, sdev->model, 16);
-	strncat(sdev->sdev_driverfs_dev.name, sdev->rev, 4);
-	return 1;
-}
-
-/**
- * scsi_load_identifier:
- * @sdev:	get an identifier (name) of this device
- * @sreq:	Scsi_Requeset associated with @sdev
- *
- * Description:
- *     Determine what INQUIRY pages are supported by @sdev, and try the
- *     different pages until we get an identifier, or no other pages are
- *     left. Start with page 0x83 (device id) and then try page 0x80
- *     (serial number). If neither of these pages gets an id, use the
- *     default naming convention.
- *
- *     The first character of sdev_driverfs_dev.name is SCSI_UID_SER_NUM
- *     (S) if we used page 0x80, SCSI_UID_UNKNOWN (Z) if we used the
- *     default name, otherwise it starts with the page 0x83 id type
- *     (see the SCSI Primary Commands specification for details).
- *
- * Notes:
- *     If a device returns the same serial number for different LUNs or
- *     even for different LUNs on different devices, special handling must
- *     be added to get an id, or a new black list flag must be added (so
- *     we use the default name, or add a way to prefix the id/name with
- *     SCSI_UID_UNKNOWN - and change the define to something meaningful
- *     like SCSI_UID_NOT_UNIQUE). Complete user level scanning would be
- *     nice for such devices, so we do not need device specific code in
- *     the kernel.
- **/
-static void scsi_load_identifier(Scsi_Device *sdev, Scsi_Request *sreq)
-{
-	unsigned char *evpd_page = NULL;
-	int cnt;
-
-	memset(sdev->sdev_driverfs_dev.name, 0, DEVICE_NAME_SIZE);
-	evpd_page = scsi_get_evpd_page(sdev, sreq);
-	if (evpd_page == NULL) {
-		/*
-		 * try to obtain serial number anyway
-		 */
-		(void)scsi_get_serialnumber(sdev, sreq);
-	} else {
-		/*
-		 * XXX search high to low, since the pages are lowest to
-		 * highest - page 0x83 will be after page 0x80.
-		 */
-		for (cnt = 4; cnt <= evpd_page[3] + 3; cnt++)
-			if (evpd_page[cnt] == 0x83)
-				if (scsi_get_deviceid(sdev, sreq))
-					goto leave;
-
-		for (cnt = 4; cnt <= evpd_page[3] + 3; cnt++)
-			if (evpd_page[cnt] == 0x80)
-				if (scsi_get_serialnumber(sdev, sreq))
-					goto leave;
-
-		if (sdev->sdev_driverfs_dev.name[0] == 0)
-			scsi_get_default_name(sdev);
-
-	}
-leave:
-	if (evpd_page) kfree(evpd_page);
-	SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO "scsi scan: host %d channel %d"
-	    " id %d lun %d name/id: '%s'\n", sdev->host->host_no,
-	    sdev->channel, sdev->id, sdev->lun, sdev->sdev_driverfs_dev.name));
-}
-
-/**
  * scsi_probe_lun - probe a single LUN using a SCSI INQUIRY
  * @sreq:	used to send the INQUIRY
  * @inq_result:	area to store the INQUIRY result
@@ -1126,11 +651,29 @@
 	return;
 }
 
+static void scsi_set_name(struct scsi_device *sdev, char *inq_result)
+{
+	int i;
+	char type[72];
+
+	i = inq_result[0] & 0x1f;
+	if (i < MAX_SCSI_DEVICE_CODE)
+		strcpy(type, scsi_device_types[i]);
+	else
+		strcpy(type, "Unknown");
+
+	i = strlen(type) - 1;
+	while (i >= 0 && type[i] == ' ')
+		type[i--] = '\0';
+
+	snprintf(sdev->sdev_driverfs_dev.name, DEVICE_NAME_SIZE, "SCSI %s",
+		 type);
+}
+
 /**
  * scsi_add_lun - allocate and fully initialze a Scsi_Device
  * @sdevscan:	holds information to be stored in the new Scsi_Device
  * @sdevnew:	store the address of the newly allocated Scsi_Device
- * @sreq:	scsi request used when getting an identifier
  * @inq_result:	holds the result of a previous INQUIRY to the LUN
  * @bflags:	black/white list flag
  *
@@ -1144,8 +687,7 @@
  *     SCSI_SCAN_NO_RESPONSE: could not allocate or setup a Scsi_Device
  *     SCSI_SCAN_LUN_PRESENT: a new Scsi_Device was allocated and initialized
  **/
-static int scsi_add_lun(Scsi_Device *sdev, Scsi_Request *sreq,
-		char *inq_result, int *bflags)
+static int scsi_add_lun(Scsi_Device *sdev, char *inq_result, int *bflags)
 {
 	struct scsi_device *sdev_sibling;
 	struct scsi_target *starget;
@@ -1204,6 +746,8 @@
 
 	sdev->random = (sdev->type == TYPE_TAPE) ? 0 : 1;
 
+	scsi_set_name(sdev, inq_result);
+
 	print_inquiry(inq_result);
 
 	/*
@@ -1240,15 +784,6 @@
 	if (inq_result[7] & 0x10)
 		sdev->sdtr = 1;
 
-	/*
-	 * XXX maybe move the identifier and driverfs/devfs setup to a new
-	 * function, and call them after this function is called.
-	 *
-	 * scsi_load_identifier is the only reason sreq is needed in this
-	 * function.
-	 */
-	scsi_load_identifier(sdev, sreq);
-	
 	scsi_device_register(sdev);
 
 	sprintf(sdev->devfs_name, "scsi/host%d/bus%d/target%d/lun%d",
@@ -1376,7 +911,7 @@
 		goto out_free_result;
 	}
 
-	res = scsi_add_lun(sdev, sreq, result, &bflags);
+	res = scsi_add_lun(sdev, result, &bflags);
 	if (res == SCSI_SCAN_LUN_PRESENT) {
 		if (bflags & BLIST_KEY) {
 			sdev->lockable = 0;

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Andries.Brouwer]

> Remove the scsi EVPD code.

Good! That simplifies many things.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Douglas Gilbert]

Andries.Brouwer@cwi.nl wrote:
>>Remove the scsi EVPD code.
> 
> 
> Good! That simplifies many things.

Good?? Just because there are millions of brain damaged
devices that can't implement rule 0 of a protocol,
Patrick removes one of the best features added to
the scsi subsystem in the 2.5 development series.

Patrick's patch is now in lk 2.5.69 .

So we are back to all the fun games of opening/
querying/closing likely looking device nodes in
the /dev space (and I speak from experience).
What a joy.

Surely there is a better way. Why not do the VPD=0x83
query on devices that claim to be SCSI-3 compliant
or better. The scsi mid level driver (and/or the
usb-storage + sbp2 LLDs) could have a sysfs parameter
such as "simple_scan". The filters discussion
showed more promise than this blunt approach.

I have contemplated putting the VPD=0x83 code in
lsscsi but it won't be pretty (e.g. requiring root
privilege, side effects including locking up
certain USB storage devices :-) ).

Doug Gilbert





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[James Bottomley]

On Mon, 2003-05-05 at 02:58, Douglas Gilbert wrote:
> Andries.Brouwer@cwi.nl wrote:
> >>Remove the scsi EVPD code.
> > 
> > 
> > Good! That simplifies many things.
> 
> Good?? Just because there are millions of brain damaged
> devices that can't implement rule 0 of a protocol,
> Patrick removes one of the best features added to
> the scsi subsystem in the 2.5 development series.
> 
> Patrick's patch is now in lk 2.5.69 .
> 
> So we are back to all the fun games of opening/
> querying/closing likely looking device nodes in
> the /dev space (and I speak from experience).
> What a joy.
> 
> Surely there is a better way. Why not do the VPD=0x83
> query on devices that claim to be SCSI-3 compliant
> or better. The scsi mid level driver (and/or the
> usb-storage + sbp2 LLDs) could have a sysfs parameter
> such as "simple_scan". The filters discussion
> showed more promise than this blunt approach.
> 
> I have contemplated putting the VPD=0x83 code in
> lsscsi but it won't be pretty (e.g. requiring root
> privilege, side effects including locking up
> certain USB storage devices :-) ).

Well, this is one of those debates where you have to weigh what you get
vs the problems caused.  EVPD inquiry was causing too many problems. 
Its use was to get a unique name for the SCSI device.  It did this by
falling back through about three levels of heuristics (ending up with
the serial number).

The heuristics employed weren't complex enough to generate a unique name
for all devices, and no-one was using them anyway.  The problems they
caused seemed to be quite real.

Here's my proposal for replacing it:

1. Unique Name is a generic block property, not an exclusively SCSI
property, so we need to add a mutable property file to the *block* class
(something like uuid or unique_id---I don't care about the name).

2. It will be mutable because it may either be set in the kernel or by
root from user level.

3. For SCSI, we will have a hotplug script that will navigate the
heuristics and generate a "unique" name for the device.  How it does
this will be entirely within the province of the scripts.

4. The generated name will be written to the mutable block property
file, so SCSI WWN will operate almost entirely at the user level.

The reason I think it should be done this way is that there are two main
uses of the unique id:

1. To find devices as they move about during bus/system reconfigurations

2. To configure multi-pathing based on the unique id's being the same.

Neither of these problems is unique to SCSI, which is why I think the
block layer is more appropriate place to solve them.

James

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Mike Anderson]

James Bottomley [James.Bottomley@steeleye.com] wrote:
> Here's my proposal for replacing it:
> 
> 1. Unique Name is a generic block property, not an exclusively SCSI
> property, so we need to add a mutable property file to the *block* class
> (something like uuid or unique_id---I don't care about the name).
> 
> 2. It will be mutable because it may either be set in the kernel or by
> root from user level.
> 
> 3. For SCSI, we will have a hotplug script that will navigate the
> heuristics and generate a "unique" name for the device.  How it does
> this will be entirely within the province of the scripts.
> 
> 4. The generated name will be written to the mutable block property
> file, so SCSI WWN will operate almost entirely at the user level.
> 
> The reason I think it should be done this way is that there are two main
> uses of the unique id:
> 
> 1. To find devices as they move about during bus/system reconfigurations
> 
> 2. To configure multi-pathing based on the unique id's being the same.
> 
> Neither of these problems is unique to SCSI, which is why I think the
> block layer is more appropriate place to solve them.

Mutability should not depend on how a uuid is set. It should depend on
what can change it.

Why block?

They are not unique to the block layer either. uuid's are unique to the
name space they are acquired in. Non-block storage devices can have
uuids. They can also have uuids without block based upper level drivers
loaded.

If you obtain a scsi_device uuid it should not be written in to a block
device attribute it should be attached to the struct device representing
the scsi device. If the attribute name is consistent "uuid" than cat
".../device/uuid" will function the same.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[James Bottomley]

On Mon, 2003-05-05 at 10:52, Mike Anderson wrote:
> James Bottomley [James.Bottomley@steeleye.com] wrote:
> Mutability should not depend on how a uuid is set. It should depend on
> what can change it.

I think the sysfs write API is sufficient, so it has to be a rw-r-r file
to allow root to write it on hotplug.

> Why block?

It's the largest available useful subset other than device itself.

> They are not unique to the block layer either. uuid's are unique to the
> name space they are acquired in. Non-block storage devices can have
> uuids. They can also have uuids without block based upper level drivers
> loaded.

True.

> If you obtain a scsi_device uuid it should not be written in to a block
> device attribute it should be attached to the struct device representing
> the scsi device. If the attribute name is consistent "uuid" than cat
> ".../device/uuid" will function the same.

by that argument, capacity, which is a property of the SCSI sd device
should be stored in the SCSI device.  It isn't, since it's a global
block device property, it's stored in the gendisk.

Unique identifiers are a property of SCSI devices, but they're not an
exclusive property.

James

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Patrick Mansfield]

On Mon, May 05, 2003 at 11:14:10AM -0500, James Bottomley wrote:
> 
> I think the sysfs write API is sufficient, so it has to be a rw-r-r file
> to allow root to write it on hotplug.
> 

If it is only ever read and written from user space, why should it be
stored in the kernel? We can just put it in a flat file or other such
database, or run the program used to get the id in the first place.

-- Patrick Mansfield


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Patrick Mansfield]

On Mon, May 05, 2003 at 05:58:28PM +1000, Douglas Gilbert wrote:
> So we are back to all the fun games of opening/
> querying/closing likely looking device nodes in
> the /dev space (and I speak from experience).
> What a joy.
> 
> Surely there is a better way. Why not do the VPD=0x83
> query on devices that claim to be SCSI-3 compliant
> or better. The scsi mid level driver (and/or the
> usb-storage + sbp2 LLDs) could have a sysfs parameter
> such as "simple_scan". The filters discussion
> showed more promise than this blunt approach.
> 
> I have contemplated putting the VPD=0x83 code in
> lsscsi but it won't be pretty (e.g. requiring root
> privilege, side effects including locking up
> certain USB storage devices :-) ).

As James said, we can get the uid from user space. This implies we need sg
(or an equivalent solution).

If the id is required before any actual use of the device, we (sometimes?
always?) need initramfs.

There is a problem with trying to use sg before sg is attached - not sure
how we can handle this. If sg could be opened generically and attached to
any nexus (i.e. scsi_device) via ioctl, we could use it not only for id's,
but for general user level scanning. Or maybe we can wait until after sg
is attached to get id's.

We still have problems with potentially locking up some devices, and we
will need some sort of black/white list for VPD usage, this would also
have been needed for an in kernel implementation; [for user space] you
would not need a kernel change to fix a problem (modify the black/white
list or other such code to prevent a VPD from being sent to a particular
device).

Plus, many of the devices do not return unique id's, even when VPD pages
are supported (especially I'm told USB) - we need a white list or other
such mechanism to tell us that id's are actually unique.

An sgid user program that does the same thing as the code removed from the
kernel would be very usefull. This could likely be incorporated into other
schemes (udev), independent of other details.

Right now, we could have an sgid that runs whenever an sg is found (sg
hotplug generated via device_register), and stores a sysfs path and the id
returned into a flat file.

-- Patrick Mansfield


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Mike Anderson]

James Bottomley [James.Bottomley@steeleye.com] wrote:
> On Mon, 2003-05-05 at 10:52, Mike Anderson wrote:
> > James Bottomley [James.Bottomley@steeleye.com] wrote:
> > Mutability should not depend on how a uuid is set. It should depend on
> > what can change it.
> 
> I think the sysfs write API is sufficient, so it has to be a rw-r-r file
> to allow root to write it on hotplug.
> 
> > Why block?
> 
> It's the largest available useful subset other than device itself.
> 
> > If you obtain a scsi_device uuid it should not be written in to a block
> > device attribute it should be attached to the struct device representing
> > the scsi device. If the attribute name is consistent "uuid" than cat
> > ".../device/uuid" will function the same.
> 
> by that argument, capacity, which is a property of the SCSI sd device
> should be stored in the SCSI device.  It isn't, since it's a global
> block device property, it's stored in the gendisk.
> 
> Unique identifiers are a property of SCSI devices, but they're not an
> exclusive property.

Yes I agree they are not exclusive to SCSI, but the same can be said of
the block argument. Block is large set, but is not the whole set of
possible uuid producing nodes. 

We could add it as a device default attribute (dev_default_attrs), but
it would produce the extra overhead like power does today for nodes that
have no uuid.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[James Bottomley]

On Mon, 2003-05-05 at 11:38, Patrick Mansfield wrote:
> As James said, we can get the uid from user space. This implies we need sg
> (or an equivalent solution).
> 
> If the id is required before any actual use of the device, we (sometimes?
> always?) need initramfs.

initramfs is only needed to find the root device.  All others can be
located later (although when depends on how the hotplug vs coldplug
issues are sorted out)

> There is a problem with trying to use sg before sg is attached - not sure
> how we can handle this. If sg could be opened generically and attached to
> any nexus (i.e. scsi_device) via ioctl, we could use it not only for id's,
> but for general user level scanning. Or maybe we can wait until after sg
> is attached to get id's.

You can now send SCSI commands directly to sd via the ioctl.

> We still have problems with potentially locking up some devices, and we
> will need some sort of black/white list for VPD usage, this would also
> have been needed for an in kernel implementation; [for user space] you
> would not need a kernel change to fix a problem (modify the black/white
> list or other such code to prevent a VPD from being sent to a particular
> device).

Yes.

> Plus, many of the devices do not return unique id's, even when VPD pages
> are supported (especially I'm told USB) - we need a white list or other
> such mechanism to tell us that id's are actually unique.

That's one of the reasons for moving itt: he heuristics are pretty
complex given the strange things devices seem to call "unique" (I can
even see devices where it's "get the label from the first available
fs").

James




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[James Bottomley]

On Mon, 2003-05-05 at 11:57, Mike Anderson wrote:
> Yes I agree they are not exclusive to SCSI, but the same can be said of
> the block argument. Block is large set, but is not the whole set of
> possible uuid producing nodes. 
> 
> We could add it as a device default attribute (dev_default_attrs), but
> it would produce the extra overhead like power does today for nodes that
> have no uuid.

Really, we could do with an extension of the class concept.  Device
could be bare bones, then the classes of device with power management,
classes of device with unique ID etc.

However, I think such a scheme might be too complex to be workable, so
just adding it to the default device attributes would be fine by me too.

James

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Mike Anderson]

Patrick Mansfield [patmans@us.ibm.com] wrote:
> An sgid user program that does the same thing as the code removed from the
> kernel would be very usefull. This could likely be incorporated into other
> schemes (udev), independent of other details.
> 
> Right now, we could have an sgid that runs whenever an sg is found (sg
> hotplug generated via device_register), and stores a sysfs path and the id
> returned into a flat file.

I believe devlabel's scsi_unique_id.c file does some of this, though I
have not looked at it closely.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Patrick Mansfield]

On Mon, May 05, 2003 at 10:46:02AM -0700, Mike Anderson wrote:
> Patrick Mansfield [patmans@us.ibm.com] wrote:

> > Right now, we could have an sgid that runs whenever an sg is found (sg
> > hotplug generated via device_register), and stores a sysfs path and the id
> > returned into a flat file.
> 
> I believe devlabel's scsi_unique_id.c file does some of this, though I
> have not looked at it closely.
> 
> -andmike

Yes, it looks very close, and has the underlying infrastructure (uses the
SCSI_IOCTL_SEND_COMMAND, not sg, so can be used for all upper level linux
scsi devices). It looks like we would need functionallity that is in the
devlabel script itself (to output just a  single ID), maybe just integrate
that into scsi_unique_id. (I did not look closely at devlabel, it has more
lines than the scsi_unique_id.c source.)

It looks like scsi_unique_id should also dump the code set, so it can pick
one code set (the same one) over anoother (if both were ever used by a
single LU).

It fails for character devices, but that is easily fixed by deletion of
the check (SCSI_IOCTL_SEND_COMMAND works for any scsi device: st, sd, sr
or sg). I deleted the check and it ran ok on a "processor" scsi device,
though the device does not support page 80 or page 83. 

scsi_unique_id should also have some sort of error checking/reporting, so
we can tell if a device is not functioning (versus does not support page
80 or 83).

I don't know how this would be integrated into the scsi device model tree,
given the current flux (class or bus for upper level devices, as well as
for the scsi_device itself).

-- Patrick Mansfield

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Douglas Gilbert]

Patrick Mansfield wrote:
> On Mon, May 05, 2003 at 10:46:02AM -0700, Mike Anderson wrote:
> 
>>Patrick Mansfield [patmans@us.ibm.com] wrote:
> 
> 
>>>Right now, we could have an sgid that runs whenever an sg is found (sg
>>>hotplug generated via device_register), and stores a sysfs path and the id
>>>returned into a flat file.
>>
>>I believe devlabel's scsi_unique_id.c file does some of this, though I
>>have not looked at it closely.
>>
>>-andmike
> 
> 
> Yes, it looks very close, and has the underlying infrastructure (uses the
> SCSI_IOCTL_SEND_COMMAND, not sg, so can be used for all upper level linux
> scsi devices). It looks like we would need functionallity that is in the
> devlabel script itself (to output just a  single ID), maybe just integrate
> that into scsi_unique_id. (I did not look closely at devlabel, it has more
> lines than the scsi_unique_id.c source.)

Patrick,
Even if you don't use sg you still have to use
the appropriate upper level driver and cope with its
vagaries (e.g. does it need O_NONBLOCK, could it
lock you out with O_EXCL). Also you need a device
file node to open: it may not be there (devfs helps
here) or could have some tricky symlink.

IMO a safe way to work for disks in lk 2.5 would be to
scan /sys/block, apply some heuristic to filter out
degenerate devices, make your own device node (i.e. mknod)
open it and use the SG_IO ioctl on that fd, etc.
This method needs root privelege.

> It looks like scsi_unique_id should also dump the code set, so it can pick
> one code set (the same one) over anoother (if both were ever used by a
> single LU).
> 
> It fails for character devices, but that is easily fixed by deletion of
> the check (SCSI_IOCTL_SEND_COMMAND works for any scsi device: st, sd, sr
> or sg). I deleted the check and it ran ok on a "processor" scsi device,
> though the device does not support page 80 or page 83. 
> 
> scsi_unique_id should also have some sort of error checking/reporting, so
> we can tell if a device is not functioning (versus does not support page
> 80 or 83).
> 
> I don't know how this would be integrated into the scsi device model tree,
> given the current flux (class or bus for upper level devices, as well as
> for the scsi_device itself).

Another approach could be to have a device node for
the scsi mid level (e.g. /dev/scsi) with an ioctl
that takes a device's toplogical address and some
parameters (e.g. VPD_83) and yields the response
of that INQUIRY (or yields an scsi status and a
sense buffer).

Doug Gilbert

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Patrick Mansfield]

On Tue, May 06, 2003 at 11:39:24AM +1000, Douglas Gilbert wrote:
> Patrick Mansfield wrote:

> > Yes, it looks very close, and has the underlying infrastructure (uses the
> > SCSI_IOCTL_SEND_COMMAND, not sg, so can be used for all upper level linux
> > scsi devices). It looks like we would need functionallity that is in the
> > devlabel script itself (to output just a  single ID), maybe just integrate
> > that into scsi_unique_id. (I did not look closely at devlabel, it has more
> > lines than the scsi_unique_id.c source.)
> 
> Patrick,
> Even if you don't use sg you still have to use
> the appropriate upper level driver and cope with its
> vagaries (e.g. does it need O_NONBLOCK, could it
> lock you out with O_EXCL). Also you need a device
> file node to open: it may not be there (devfs helps
> here) or could have some tricky symlink.

OK, I suppose those can be worked out one way or another.

The hotplug/sysfs should also give us a kdev that we can use for a
(temporary) mknod - one we can use to get an id (at least for upper level
devices, but I don't see why we would want to get an id for anything else
- if we have no upper level device, we have no user access to the
  scsi_device).

> IMO a safe way to work for disks in lk 2.5 would be to
> scan /sys/block, apply some heuristic to filter out
> degenerate devices, make your own device node (i.e. mknod)
> open it and use the SG_IO ioctl on that fd, etc.
> This method needs root privelege.

I thought Greg's udev approach was going to be for all hotplug, no cold
plug.

> Another approach could be to have a device node for
> the scsi mid level (e.g. /dev/scsi) with an ioctl
> that takes a device's toplogical address and some
> parameters (e.g. VPD_83) and yields the response
> of that INQUIRY (or yields an scsi status and a
> sense buffer).

Can something like that be done for a /dev/sg today? It would be very
useful, not only for VPD/id like commands, but also for user level
scanning.

That is open some /dev/sg via an ioctl (or ?) attach it to a nexus. If
there is an existing scsi_device with a matching nexus, it can attach to
it, else create an sdev via scsi_alloc_sdev, attach to it and go.

Then we can send whatever commands we want via current sg interfaces.

-- Patrick Mansfield

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Douglas Gilbert]

Patrick Mansfield wrote:
> On Tue, May 06, 2003 at 11:39:24AM +1000, Douglas Gilbert wrote:
> 
>>Patrick Mansfield wrote:

<snip/>

>>Another approach could be to have a device node for
>>the scsi mid level (e.g. /dev/scsi) with an ioctl
>>that takes a device's toplogical address and some
>>parameters (e.g. VPD_83) and yields the response
>>of that INQUIRY (or yields an scsi status and a
>>sense buffer).
> 
> 
> Can something like that be done for a /dev/sg today? It would be very
> useful, not only for VPD/id like commands, but also for user level
> scanning.

It can be. There are a few details to be worked out.
In lk 2.4 for example the sg driver is not initialized
if there are no SCSI devices. That would cause a chicken
and egg type situation if sg was used to do user level
scanning to find the first scsi device. What major/minor
should /dev/sg have? (It could be a misc device and get
a minor reserved).

> That is open some /dev/sg via an ioctl (or ?) attach it to a nexus. If
> there is an existing scsi_device with a matching nexus, it can attach to
> it, else create an sdev via scsi_alloc_sdev, attach to it and go.
> 
> Then we can send whatever commands we want via current sg interfaces.

Sounds good. Only allow /dev/sg to have one nexus at
a time "open" (per file descriptor)? Could it
delete an existing nexus?

Doug Gilbert

Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Patrick Mansfield]

On Tue, May 06, 2003 at 03:58:02PM +1000, Douglas Gilbert wrote:
> Patrick Mansfield wrote:

> > Can something like that be done for a /dev/sg today? It would be very
> > useful, not only for VPD/id like commands, but also for user level
> > scanning.
> 
> It can be. There are a few details to be worked out.
> In lk 2.4 for example the sg driver is not initialized
> if there are no SCSI devices. That would cause a chicken
> and egg type situation if sg was used to do user level
> scanning to find the first scsi device. What major/minor
> should /dev/sg have? (It could be a misc device and get
> a minor reserved).

If minor space size increases you could use the the max sg minor or some
large minor number, or just get any available major/minor (I don't know
details of this area, or if there is such code for char devices in the 2.5
kernel). For starters you could use sg's highest minor (255).

/dev/sg could be used instead of any of the /dev/sgN entries.

> > That is open some /dev/sg via an ioctl (or ?) attach it to a nexus. If
> > there is an existing scsi_device with a matching nexus, it can attach to
> > it, else create an sdev via scsi_alloc_sdev, attach to it and go.
> > 
> > Then we can send whatever commands we want via current sg interfaces.
> 
> Sounds good. Only allow /dev/sg to have one nexus at
> a time "open" (per file descriptor)? Could it
> delete an existing nexus?

I was thinking of a clone-like open - I was looking for tty code that does
this, but can't figure out or find it (/dev/pty, drivers/char/pty.c plus
some generic tty code?). Such that each open of /dev/sg gets its own
pseudo device. There is reference to this in the linux device drivers book
(chapter 5 "cloning the device on open"), but I don't see how their
example passes back the dev to the caller of the open. Maybe someone has
pointers to functioning pseudo device driver code.

You could have multiple opens per nexus (multiple simultaneous opens of
/dev/sg, and each one attaches to the same nexus, probably similiar to
multiple opens on a for example /dev/sg0). That might be odd, maybe that
could happen if we were doing user level scanning + id usage at the same
time.

I don't think it should be able to delete a nexus (i.e. scsi_device) for
now, but it might eventually be good to allow it to add (or keep) a nexus
around after it is attached - so we could scan, and if a scsi_device/nexus
is found to exist, leave the scsi_device, and then trigger other scsi
upper level attaches. 

(Going beyond what we need now, for multipath I would like to be able to
arbitrarily remove or attach any nexus to any scsi_device from user
level. This might best be done via sysfs interfaces.)

Just having a /dev/sg that works for one open, and attaches to one nexus,
and then allows sg commands would be a nice start, and might even be
enough for 2.5 usage.

-- Patrick Mansfield