Re: WWID / SerialNo in sysfs?

[Kurt Garloff <garloff@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

On Mon, Feb 09, 2004 at 04:48:02PM -0800, Patrick Mansfield wrote:
> On Tue, Feb 10, 2004 at 01:19:28AM +0100, Kurt Garloff wrote:
> Yes, and (a) is harder with the host number being always incremented.
> 
> > Thus my patch to export the names.
> 
> Does that only narrow the scope of the problem? If you have two host
> adapters of the same name, the name is not enough to identify a particular
> adapter, and we have to fall back to something else. Using the full sysfs
> path with a wildcard for the host number would cover some cases (for
> example, if the PCI bus id were constant).

scsidev the host number and the unique_id (ioport) by default for 
historical reasons. But you can construct path names using scsi.alias.
You can encode the hostname and the unique_id (hostid) in there
to construct a path.

> > > Also has these items that could be done in scsidev:
> > > 
> > > - a white/black list text file, so we don't need to rebuild a kernel or
> > >   recompile the user binary to add or remove devices from the lists
> > 
> > I don't understand what you're telling me here.
> 
> That we should have a white and black list, since there are devices that
> do not properly support page 0x80 or page 0x83, and that it should not be
> compiled into the command.

Ah, I see.

> If you're system has all known good devices (high end server, and no low
> cost USB mass storage devices will be attached to it), you might want to
> use a black list; if you're system is generic, you might want a white
> list.

Lucky enough, all devices I tested so far survived scsidev ...
And I did not get bug reports. 

Maybe the patch to do it in the kernel should have just avoided it
for usb-storage and everything would have been fine ;-)

More seriously: I wonder whether a devices_are_likely_broken flag in
the host template that is set by usb-storage wouldn't save us from
a lot of hacks in SCSI.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]