On Tue, Mar 11, 2008 at 10:43:45PM +0530, aakash berde wrote: > I tried as per your suggestions but still I didn't get the positive result. > I search for the driver and I found one node to which both mpt driver and sd > driver is attached. > For both prtconf -Dv | grep sd and prtconf -Dv | grep mpt I get same node. > When I send the uscsi command to this node I get the error meassge > "Inappropriate Ioctl for device".
Please post the output of prtconf -v somewhere and give us the URL. Having both mpt and sd attached to the same node is impossible and makes no sense. > What I have to do is to detect all SCSI devices on system attached to sd > driver and communicate with all one by one using uscsi(fd,USCSICMD,..). YES! RIGHT! > Can I get some answers to my queries from this forum? > 1. How we can get the device name of the devices in /dev/rdsk/ or /dev/dsk > without using ioctls. Is there any theory reference is there to crosscheck ? What do you mean by device names? Like c1t2d0s2? You can get these from libdevinfo. > 2. what is difference in /dev/cfg and /dev/rdsk? /dev/cfg is where HBAs (and some other nexi) are exposed. /dev/rdsk is where disk targets(often but not always sd) are exposed. > 3. when I send uscsi(fd,USCSICMD,...) to devices in /dev/rdsk I get the > proper result but not for devices in /dev/cfg. What should be the reason? I'm afraid I'm not communicating this well. Le me be as clear as I possibly can. An HBA appears as a nexus in the device tree. A nexus acts as an attachment point for other drivers. The node itself may or may not support direct manipulation (as with ioctl(2), read(2), etc.) from userland. The device nodes normally hanging off HBA nexi are typically disks, enclosure services targets, tape drives, tape robots, DVD drives, etc. These device nodes are leaves; they do not provide attachment points for other devices. These devices have something in common: they represent SCSI targets. Most SCSI target drivers support uscsi. The HBA is a SCSI initiator, not a SCSI target. It does not support uscsi. If you want to perform uscsi operations on SCSI targets, do not open the HBA node. Open the target node(s) instead. It may or may not be necessary to access the HBA directly on other operating systems to perform direct SCSI I/O to targets. It is not necessary (or, generally, possible) to do so on any OpenSolaris-derived operating system. Things don't work that way here. Instead of forcing you to know about the HBA, we abstract the idea of I/O transports away by allowing providers of those transports to provide attachment points for higher-level drivers for devices that require such transports. That is how an HBA driver works here. You don't need to know or care about it. Just use the target node. It might be worthwhile for you to read two additional documents: SCSI Architecture Manual: http://www.t10.org/ftp/t10/drafts/sam4/sam4r13e.pdf Any general reference on Unix device management, such as chapter 16 of Valhalia's Unix Internals. > 4. Where are the instances for device in /dev/cfg/ on system? Just ignore them. > 5. Is there any documentation on uscsi commands? Yes. uscsi(7I). If you mean the SCSI commands themselves, start with SPC-4 and SBC-3 at t10.org. They define the SCSI protocols. There are separate addenda for streaming devices, optical devices, and so on. > 6. Is there any complete project instead of just source files on opensolaris > source browser to check the uscsi functionality? What's the difference between a complete project and source files? Projects are comprised of source files. Consolidations are comprised of projects. The source browser provides access to the source. I don't understand what you want. -- Keith M Wesolowski "Sir, we're surrounded!" Fishworks "Excellent; we can attack in any direction!" _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
