svn commit: r195534 - in head: etc/mtree include lib/libcam sbin/camcontrol share/man/man4 sys/cam sys/cam/ata sys/cam/scsi sys/conf sys/dev/advansys sys/dev/ahci sys/dev/aic7xxx sys/dev/amd sys/de...

[Ivan Voras]

2009/7/10 Poul-Henning Kamp <phk at phk.freebsd.dk>:
> In message <86skh4u6kh.fsf at ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr
> ites:
>>"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>>> I'm all for unifying the namespace, but still remember how much pain
>>> the "didn't find that disk, lets renumber all of the rest of them"
>>> causes, so I tend to prefer physically bound names.
>>
>>cXtYdZ for the win!
>
> Actually, maybe the solution is to push glabel much more agrressively
> (ie: read sysinstall)

Publishing drive IDs from the driver to the GEOM layer will naturally
and automatically provide a reasonable unique ID to be used by
sysinstall et al.

It's done for ATA, but AFAIK not for CAM. I'm a bit puzzled about that
- it looks trivial?

I see that "camcontrol inquiry -S" works:

# camcontrol inquiry da0 -S
B399P6A04GRS

...but apparently not in all cases - the same on another machine (a
virtual machine under VMWare) doesn't print out anything.

Then there are non-da devices:

# camcontrol inquiry mfid0 -S
camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed
cam_lookup_pass: No such file or directory
cam_lookup_pass: either the pass driver isn't in your kernel
cam_lookup_pass: or mfid0 doesn't exist

I don't know enough about the SCSI drivers to conclude anything useful.