Re: [PATCH] st: Do not rewind for SG_IO

[Hannes Reinecke <hare@suse.de>]

On 02/03/2014 10:58 PM, Jeremy Linton wrote:
> On 2/3/2014 2:51 PM, Kay Sievers wrote:
>> This is not simple and not going to happen. Sibling devices in /sys cannot
>> have a relationship in udev, there are only parent/child dependencies.
> 
> 	Ok.. so if we can't ignore all the "spare" device nodes in a given /sys entry
> for a given device. Why open the device to scan it?
> 
> 	I've often wondered why the serial number isn't part of the data in /sys
> along with the manufacture/model. The last tape drive I saw that failed to
> respond to inquiry page 0x80 was over a decade ago (probably manufactured in
> the early 90s). So enabling it just for tape is pretty safe.
> 
> 
> 	Matching Manufacturer/model/serial is going to be better than anything your
> going to get out of 0x83 anyway. That data is guaranteed to be there, but its
> also guaranteed to be unreliable (every device, and every port has a slightly
> different set of descriptors they choose to support).
> 
> 	Plus, your not going to have issues accidentally rewinding a device, or
> resetting a tape density, or accidentally turning compression off if you don't
> open the device.
> 
And indeed, I have been wondering about this, too.
And (again) it is something which has been on my To-Do list for a
long time.

Moving EVPD page 0x83 (and maybe 0x80, too) into sysfs will save
quite a lot of headache we have currently; udev won't have to
call 'sg_inq', information will be present even though the
device itself might be temporarily unavailable yadda yadda.

So I've decided to bite the bullet and sent out a patch,
check for 'Add EVPD page 0x83 entries to sysfs'.

Reviews are welcome.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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