It only been two days and it seems appropriate to refer
to Martin Petersen's summation of persistent naming issues again:
http://marc.theaimsgroup.com/?l=linux-scsi&m=101840990116069&w=2
As for "scsihosts" its current syntax is:
scsihosts=aic7xxx:sym53c8xx::aic7xxx
This could be extended to
scsihosts=aic7xxx[pci=00:0c.0]:sym53c8xx::aic7xxx
and if "pci=" was assumed to be the default then this
would have the same effect as:
scsihosts=[00:0c.0]:sym53c8xx::aic7xxx
assuming there was a aic7xxx controlled HBA at that PCI slot.
No consistent persistence here, just a little more precision.
> Now don't get me wrong, I'm not saying the patch isn't usefull, but the
> patch doesn't provide *any* guarantee of consistent device naming and so
> using that as a reason to put the patch into the mainstream kernel is
> utter crap. Go ahead and make your case for why it should be in the
> kernel, but don't use reasons that aren't correct.
>
> > But actually, the patch is not meant to be the holy grail of persistent
> > device naming. But it enables userspace tools to collect information
> > * reliably
> > (fails so far due to possible open() failures with unknown
> > relation to the corresponding sg device (which could be opened))
>
> This can be done without your patch (the mapping from /dev/sg to /dev/sd?
> or /dev/st? or /dev/scd? or whatever is not impossible from user space
> without your patch, it just requires a user space tool to open the files
> and start comparing host/bus/id/lun combinations from dev file to dev
> file).
>
> > * without too much trouble
>
> This part is true enough, it is easier to read the map file than to
> program the information retrieval I mentioned above.
You can say that again. Joerg Schilling is still some way
from getting it right in cdrecord, SANE still has problems
in this area (and I rewrote the scsi scanning code). Kurt
and I have a fair amount of experience in this particular
area. There are lots of gotchas ...
Kurt's implementation is worthy of note as well. When I have
pondered this problem I just wanted to poke each sg kdev_t into
the corresponding Scsi_Device. People objected that this was
a layering violation. Kurt has added a new upper level callback
find_kdev() which is cleaner. Based on this new callback we
could add a new mid level ioctl that yielded the principal
(k)dev_t (i.e. sd, st or sr) and the generic one. That would
make life easier for cdrecord and cdparanoia (and sg_utils).
As for SANE, by looking at /proc/scsi/map it could only analyse
sg devices that where "printer" or "processor" device types.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/