Xref: utzoo comp.unix.internals:2391 comp.unix.sysv386:6188
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!randvax!segue!mark
From: mark@segue.segue.com (Mark Kampe)
Newsgroups: comp.unix.internals,comp.unix.sysv386
Subject: Re: SCO UNIX *double* device driver
Message-ID: <6775@segue.segue.com>
Date: 20 Mar 91 15:27:24 GMT
References: <905@zeusa.UUCP>
Reply-To: mark@segue.segue.com (Mark Kampe)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 39

In answer to the question "How can I filter all the data going to and from
a device driver" ...

In some cases you may be able to use STREAMS, but these are not available
in all flavors (and configurations) of UNIX.  If you are willing to put 
your immortal soul in perril however, there is a pretty easy, efficient,
and sure-fire  way to address your problem.

All calls to a device driver (resulting from system calls or internal I/O
requests) are made through some variation of the device driver switch.
Some systems have one such table, some two, and a few have three.  The
entry points also vary from system to system, but they all have open,
close, read, write, ioctl and strategy.  The principle calls to the driver
that don't go through the device driver switch are interrupts (and some
kernels even pass those through the driver switch).

If you know which driver you want to filter for, you can modify the 
appropriate devsw/bdevsw/cdevsw/intrsw/... entries to point to your
driver (rather than the real driver).  Once this is done, you will get
control everytime anybody tries to do anything with the intercepted driver
(with the possible exception of interrupts).  You can do what ever processing
you intended to do, and then pass the operations on to the real driver.

Note however that this feat should only be attempted by trained professionals
and kids should not try this one at home.  More specifically:

	(1) depending on what you do, you may introduce horrible
	    performance problems into your system - particularly if
	    you use this trick (as suggested) to "mirror disks".

	(2) unless you are EXTREMELY CONFIDENT about your understanding
	    of locking, synchronization, interrupt enabling and other
	    such assorted "house keeping" chores, you are likely to 
	    unleash a Pandora's Box of horrible bugs in your system.

	(3) you may face derision from your peers and the loss of your
	    technical soul.

---mark---