Mike Brown wrote: > > Hi all, > > I'd like to create some ioctl cmd's for the adapter driver that I am > writing. Looking at the code, it seems that the way to do this is to > just add an appropriate ioctl cmd to include/scsi/sg.h and the I'm not sure sg.h is the correct place to put your adapter driver's ioctl codes. > scsi upper/mid layers will eventually call the adapter's ioctl() function > after not recognizing the particular ioctl cmd. (I'm using the ide-scsi > driver as a reference which is the only driver which uses the > SG_SET_TRANSFORM ioctl cmd according to sg.h). > > So what's my problem? My problem is that I need to issue an ioctl() to > my adapter driver when there are no devices on the bus. Because there are > no devices on the bus, I can't open /dev/sg0 and therefore cannot issue an > ioctl. > > I have thought of a few possible solutions, but wanted to see if someone > had a better idea: > > 1. Don't use ioctl() and just communicate over /proc > > Yes this solution would work. However, it is my understanding that > writing to a /proc file is a linux specific semantic and may not be > available on other UNIX platforms. (I'd like to keep the code somewhat > portable). Can anyone comment on this? It will work but /proc does have its shortcomings. For example, if 'cat /proc/scsi/sg/debug' is repeatedly executed on a busy sg driver, output misalignments will be observed. > 2. Hack - have the adapter driver report a phony scsi device > > Similar to what scsi_debug does I could create a bogus device and then > be able to do what i need by opening that device. I don't like this idea > much. James Bottomley's reply to this was interesting. > 3. Personally ask Peter Anvin for my own /dev/myweirdhba entry. > This isn't the cleanest solution either. > > The following idea I like best since its generic and could be used in the > future by other scsi adapters. > > 4. Have linux scsi developers agree on asking Peter Anvin for /dev/scsi0, > /dev/scsi1, /dev/scsi2, etc... > > The idea here would be that /dev/scsi0 would be the first scsi adapter > on the machine, /dev/scsi1 would be the second, /dev/scsi2 would be the > third, etc. etc. Userspace programs would then be able to issue ioctl()'s > directly to any scsi adapter by first opening /dev/scsi0 etc. Perhaps you could look at my scsimon upper level driver: http://www.torque.net/scsi/scsimon.html It is primarily intended to support hotplugging however it does allow you to scan the attached scsi hosts (even if there are no SCSI devices attached). An ioctl could be added to select one of those hosts so that subsequent ioctls (that didn't match a "case" in scsimon) could be forwarded to that host. Also scsimon uses the "misc" char device with a minor number that is reserved for private use because hpa wouldn't issue scsimon a number. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
