Due to the name clash between my scsiinfo driver and a utility of the same name, this driver has been renamed "scsimon". Consequently the web page has become: http://www.torque.net/scsi/scsimon.html The tarball on that page includes a kernel patch against lk 2.4.2, a test program called sm_test.c and a simple scsi.agent for loading scsi upper level drivers (e.g. sr_mod). One extension that I have asked several people about is media ready/not_ready alert via the hotplug infrastructure. This would involve adding an ioctl to scsimon that would spawn a kernel thread which would periodically poll the given device (with a TEST UNIT READY command). When a state change occurred then a notification would sent to /sbin/hotplug with either "ready" or "not_ready" set as the ACTION. Sending TEST UNIT READY commands to a device being actively used by another driver could cause problems. In such cases supplying a notification to /sbin/hotplug when the Scsi_Device::changed flag toggled from 0 to 1 may be useful. [This flag indicates that some driver has seen a UNIT ATTENTION reported.] With help from Oliver Neukum, I have been playing around with making sg handle "dirty" detaches. It is more difficult than expected, but possible. [Some midlevel changes would also be useful.] While testing, I noticed that the scsi_devicelist variable is exported. This allows an adapter driver to scan that list, looking for a particular driver and perhaps call the detach() method. [N.B. The scsi midlevel has been bypassed.] These detach() calls could be pre-emptive. If one was sent to the scsimon driver then that would cause an alert to be sent /sbin/hotplug. Via some user space magic, an application like SANE might gracefully let go of its sg file descriptor. An adapter driver like usb/microtek might then notice its usage count had dropped to zero and then unregister and unload itself. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
