From: Douglas Gilbert <dougg@torque.net>
To: linux-hotplug@vger.kernel.org
Subject: [experimental] scsimon driver [was scsiinfo driver]
Date: Wed, 14 Mar 2001 01:01:12 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-98453204711721@msgid-missing> (raw)
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
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
reply other threads:[~2001-03-14 1:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-98453204711721@msgid-missing \
--to=dougg@torque.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).