No, this is not true. If you add a new controller (for some new disks in
a new external enclosure or whatever), and that controller uses the same
driver as other controller(s) in your system, then you have no guarantee
of order. For example, adding a 4th aic7xxx controller to your system
might or might not place the new controller at the end of the list
depending on PCI scan order, etc. There simply is *no* guarantee here of
any consistent naming, so don't bother trying to claim there is.
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.
> Both things I consider important and useful.
>
> The patch basically does provide two pieces of information:
> * mapping between sg vs. other high level devices
This I think is usefull.
> * mapping CBTU to high-level devices
This I don't think is usefull at all. It's no more reliable than our
current system and people that are depending on this to solve their "I
can't tell what device is what" delima are going to be sorely upset when
they realize that hardware changes can change this stuff around just as
fast as it changes around the /dev/sd? mappings.
> The latter one is enough for many setups,
The latter one is just as broken in design as the original /dev/sd?
enumeration problem (which stands to reason since this method also is an
enumeration method, it's just that instead of enumerating the disks
starting at 0, we are enumerating the SCSI controllers starting at the
first one we find and going from there).
> and the former can be used for
> more elaborate solutions involving userspace tools more advanced than the
> simple script I included in the patch.
Which is the much better way to go.
> If you want to go for the holy grail, you may either come up with a
> unique address at hardware level (which does currently not exist for all
> types dealt with by the SCSI subsystem) and make it available to SCSI mid
> level or use signatures that allows you to find devices back. LVM, e.g.
> does the latter.
> But at this moment, I fear, neither of them are possible in all cases.
>
> Regards,
> --
> Kurt Garloff <kurt@garloff.de> [Eindhoven, NL]
> Physics: Plasma simulations <K.Garloff@TUE.NL> [TU Eindhoven, NL]
> Linux: SCSI, Security <garloff@suse.de> [SuSE Nuernberg, DE]
> (See mail header or public key servers for PGP2 and GPG public keys.)
-- Doug Ledford <dledford@redhat.com> 919-754-3700 x44233 Red Hat, Inc. 1801 Varsity Dr. Raleigh, NC 27606 - 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/