Re: IDs

Re: IDs

[Andries.Brouwer]

> 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

Re: IDs

[Patrick Mansfield]

On Tue, Jan 07, 2003 at 03:19:45AM +0100, Andries.Brouwer@cwi.nl 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

Re: IDs

[Andries.Brouwer]

> 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

Re: Re: IDs

[Greg KH]

On Tue, Jan 07, 2003 at 11:55:00AM +0100, Andries.Brouwer@cwi.nl 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


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: IDs

[Patrick Mansfield]

On Tue, Jan 07, 2003 at 11:55:00AM +0100, Andries.Brouwer@cwi.nl 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


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel