> Instead of truncating the id, we need a new scsi_uid field allocated
> to whatever size required.
> And, a descriptive string put in the name, rather than the id, such as:
> scsi disk
[I changed the Subject line "Re: inquiry in scsi_scan.c" since people
are still discussing devices with a buggy INQUIRY response;
maybe unnecessarily - all details are well understood, and
patches fixing all problems have been posted, but in any case
it is best to separate both threads.]
Maybe I should ask you to explain more in detail what purpose
you have in mind. If I read your code and hear you talking
it sounds like you would like to have a string identifying
the device. But in many cases no such string exists.
Moreover, what precisely is "the device"?
If I have a Compact Flash card reader and read CF cards,
is the device the reader? Or the card? Or the combination?
If I have an Imation FlashGo! reader, and insert a SmartMedia
adapter, and read a SmartMedia card, is the device the reader,
the reader plus adapter, the card?
If the device is the reader, then it will have a different size,
partitioning and contents each time we see it.
If the device is the card, then we need a different driver
each time we see it.
What do you want to recognize with this ID, and why?
Andries
Andries -
On Tue, Jan 07, 2003 at 01:00:47AM +0100, [email protected] wrote:
> Maybe I should ask you to explain more in detail what purpose
> you have in mind. If I read your code and hear you talking
> it sounds like you would like to have a string identifying
> the device. But in many cases no such string exists.
Yes, but where one exists we can use it. Any recent SCSI disk should end
up with a unique value in (what is currently) sdev->name. We can tell if
the id sdev->name should be unique by looking at the first byte (it is not
unique if the value is 'Z', SCSI_UID_UNKNOWN).
> Moreover, what precisely is "the device"?
> If I have a Compact Flash card reader and read CF cards,
> is the device the reader? Or the card? Or the combination?
> If I have an Imation FlashGo! reader, and insert a SmartMedia
> adapter, and read a SmartMedia card, is the device the reader,
> the reader plus adapter, the card?
The scsi_device, whatever it represents. For removable media, we should
either make sure sdev->name has a value for this storage such that we know
the id is not unique, or we should check (and export to sysfs) the
sdev->removable flag. I haven't checked what currently gets put into
sdev->name for CF cards (or even if removable is properly set).
> If the device is the reader, then it will have a different size,
> partitioning and contents each time we see it.
> If the device is the card, then we need a different driver
> each time we see it.
>
> What do you want to recognize with this ID, and why?
>
For use with device naming/persistence.
For devices with a unique ID, we can always give them the same name;
non-unique ID's can be named based on their location
(host/channel/target/lun).
-- Patrick Mansfield
> We can tell if the id sdev->name should be unique by looking at
> the first byte (it is not unique if the value is 'Z'),
> SCSI_UID_UNKNOWN.
Such things are nontrivial.
% cat /sysfs/devices/ide-scsi/0:0:0:0/0:0:0:0/name
SHP CD-Writer+ 8200 [
Here the serial number consists of the '[' only.
(And this is not because of truncation.)
I can see your intentions, but view these names/ids more
like heuristics than like reliable data.
More or less like mount, which will usually figure out the
filesystem type for you, but no guarantees are given.
And where we have heuristics only, it cannot be "wrong"
to truncate at 50 positions or so. The heuristic does
not become appreciably weaker.
(And, in case of heuristics, I like 98% heuristics better
than 99.98% heuristics. They keep you honest. No important
things will depend upon them. With 99.98% one may forget
that it is a heuristic.)
Andries
On Tue, Jan 07, 2003 at 03:19:45AM +0100, [email protected] wrote:
> > We can tell if the id sdev->name should be unique by looking at
> > the first byte (it is not unique if the value is 'Z'),
> > SCSI_UID_UNKNOWN.
>
> Such things are nontrivial.
Yes ...
> And where we have heuristics only, it cannot be "wrong"
> to truncate at 50 positions or so. The heuristic does
> not become appreciably weaker.
But, we don't have to truncate, we should just allocate as many bytes as
we need, and store the information.
And, the sysfs name should not store the id.
-- Patrick Mansfield
> But, we don't have to truncate, we should just allocate as many bytes as
> we need, and store the information.
> And, the sysfs name should not store the id.
OK. It seems that we are in total agreement.
Time for the next question.
An id is constructed, that in many cases identifies something.
How do you plan to use this? Is it already in use somewhere?
The sysfs tree does not contain device nodes.
Do you plan a user space utility that figures out that
the ID "SHP CD-Writer+ 8200 [" belongs to /dev/hdd
which also is /dev/sr0?
The id is not suitable as a user space name. Moreover,
it is a heuristic only, and user space needs unambiguous names.
What user space names do you want to use?
Andries
On Tue, Jan 07, 2003 at 11:55:00AM +0100, [email protected] wrote:
>
> The sysfs tree does not contain device nodes.
And that will remain true.
> Do you plan a user space utility that figures out that
> the ID "SHP CD-Writer+ 8200 [" belongs to /dev/hdd
> which also is /dev/sr0?
Yes. Well, at least I plan on creating such a utility once more of the
kernel is converted over to using sysfs :)
thanks,
greg k-h
On Tue, Jan 07, 2003 at 11:55:00AM +0100, [email protected] wrote:
> > But, we don't have to truncate, we should just allocate as many bytes as
> > we need, and store the information.
>
> > And, the sysfs name should not store the id.
>
> OK. It seems that we are in total agreement.
> Time for the next question.
>
> An id is constructed, that in many cases identifies something.
> How do you plan to use this? Is it already in use somewhere?
It's not in use in the main-line kernel.
I forgot to mention that I'm using the id in scsi mid-level multi-path
code, it has the same problem (the id is not always unique, plus other
major issues to deal with).
I'm not working on any device naming/persistence code, although I have
given thought to solutions. Any solution there might apply to multi-path
usage. But the multi-path cannot easily be moved to user space until we
have complete user level scsi scanning.
Is anyone currently writing device name solutions based on the scsi id?
> The sysfs tree does not contain device nodes.
> Do you plan a user space utility that figures out that
> the ID "SHP CD-Writer+ 8200 [" belongs to /dev/hdd
> which also is /dev/sr0?
With the current code, any utility would be scsi specific (it could only
name scsi devices based on an id, others would get a default name), so it
would only cover /dev/sr0. I don't know much about IDE capabilities.
> The id is not suitable as a user space name. Moreover,
> it is a heuristic only, and user space needs unambiguous names.
If we had a complete white/black list of devices with/without a unique id,
there would be no ambiguity. Such a list could be generated by asking the
user/administrator each time an unknown device is added to the system (or
have a safe default); we could also have a white/black somewhere (for use
from user space), much like we have with scsi_static_device_list in
scsi_scan.c today.
A user level white/black list is also useful for scanning, especially for
user level scanning, and for kernel scanning if we can access it before
starting the scan (via ramdisk at boot time).
> What user space names do you want to use?
Maybe have a configurable starting point (like /devnames, maybe
something that does not collide with /dev, perhaps we can generate a
/dev matching exactly what we have today), much like a mount point, or
like devfs. I don't know of any good reasons for a file system.
In any case, right now we should fix the scsi sysfs name, and add (and not
truncate) a uid to scsi_device.
-- Patrick Mansfield
>> The id is not suitable as a user space name. Moreover,
>> it is a heuristic only, and user space needs unambiguous names.
> If we had a complete white/black list of devices with/without a unique id,
> there would be no ambiguity.
You mean for the devices on the white list.
But most devices will not be on the white list.
Our perceptions differ, I think. My impression is that chaos
is the norm, and well-behaved devices are the exception.
I find very good behaviour in fixed hard disks.
Stuff by Maxtor, Seagate, IBM, etc - a very small collection
of very experienced manufacturers with high quality products.
SCSI CDROM drives or tape drives or scanners are messier.
USB storage devices are much messier - very basic parts of the
protocol are regularly broken.
So to me the approach of an id together with a blacklist
seems unworkable.
As you say - we can make a best effort and get a string that
with some luck identifies the device uniquely. But no guarantees
given.
Maybe that again means that the S/Z distinction can be dropped.
Andries
On Tue, Jan 07, 2003 at 07:54:11PM +0100, [email protected] wrote:
> > If we had a complete white/black list of devices with/without a unique id,
> > there would be no ambiguity.
>
> You mean for the devices on the white list.
> But most devices will not be on the white list.
I mean if it is not on the white list, treat it as black listed or ask
for user/admin input, so we safely handle the id.
> Our perceptions differ, I think. My impression is that chaos
> is the norm, and well-behaved devices are the exception.
For usb storage, cd's, and cheap storage yes, chaos.
> As you say - we can make a best effort and get a string that
> with some luck identifies the device uniquely. But no guarantees
> given.
Yep.
> Maybe that again means that the S/Z distinction can be dropped.
We still want to tell page 0x83 (starts with a number) from page 0x80
(currently starts with S) from default values (currently starts with Z).
Dropping the Z in favour of an empty string would be good.
-- Patrick Mansfield