Its a brave new world for the mpt scsi driver.
By timatworkhomeandinbetween on Sep 04, 2008
I remember that when you wanted to add a driver to control a scsi device you added the driver to the right directory, created a driver.conf file, edited that file to select what target/lun combination you wanted and maybe set some properties or address filters, ran devfsadm or did a boot -r and it all just worked...
Now it appears I am old fashioned and that the mpt scsi driver became one of these new fangled "self identifying" HBA devices with the solaris 10 mpt patch 125081-09 and later revisions that are now in the Kernel patch and hence in the latest updates to solaris 10.
We did document this in the scsi(4) manual page its just I don't think we really documented that mpt had changed type.
So if you add a SL500 tape changer device to a mpt scsi bus a /devices node will be created by mpt now rather than the target driver. As mpt has no idea what driver will attach to that it uses the name "sgen" for scsiclass 08, st for scsiclass 01, sd for scsi classes 00,03,05. This is the big difference previously the /devices node would only have appeared when your target driver attached it and it would have used the name of your driver so you could search for it with find during your solutions install script and put a nice simple entry in /etc/devlink.tab to get a /dev symbolic link.
Now you will always get a /devices node called sgen@XXX for a changer device attached to mpt as soon as mpt attaches and probes the bus, without any modification to sgen.conf sgen will attach to it. so how do I get my "foo" driver to attach to it?
"man -s4 scsi" says that you will get a list of compatible properties attached to the /devices node, ranging from some very specific strings though to very generic strings. The sgen driver picks up on the very generic entry, but you can use update_drv -a -i "specific compat property" foo to insert the association ahead of sgen. At this point sgen should let go of the device and the foo driver will attach to it. You can undo this association by using update_drv -d -i "specific compat property" foo to delete the association and allow sgen to re-attach to the changer device.
So for my sl500 how do i see these compatible properties..
prtconf -v | grep -i stk
value='scsiclass,08R.vSTK.pSL500.r1126' + 'scsiclass,08.vSTK.pSL500.r1126' + 'scsiclass,08R.vSTK.pSL500' + 'scsiclass,08.vSTK.pSL500' + 'scsa,08.bmpt' + 'scsiclass,08R' + 'scsiclass,08' + 'scsiclass'
so to add my foo driver ahead of sgen and take control of all scsi class 08 changers attached to STK SL500's I used
update_drv -a -i '"scsiclass,08.vSTK.pSL500"' foo
and to get symbolic links under /dev/foo I added this line ( tab not spaces) to /etc/devlink.tab
instead of the old fashioned form ...
all without editing a single driver.conf file...
Of course the old /dev links for sgen will still be there under /dev/scsi/changer/ but they can be removed with a devfsadm -C
The same would have to be done for the SL500's tape devices but they would show up under /devices as a node with a name like st@XXXX and you would have to add an alias for them using update_drv -a and a line in /etc/devlink.tab using name=st; my_driver
certainly some installation programs and solutions will come unstuck when faced with this new mpt behaviour. Hopefully this will help explain what you are seeing.