SCO UNIX *double* device driver

Mark Warren mwarren at rws1.ma30.bull.com
Wed Mar 20 22:34:35 AEST 1991


hendrik at zeusa.UUCP (Hendrik Vermooten) writes:


>I need to "channel" all I/O going to and from a device, through my own
>handler routine (this routine itself uses hardware to do its job).

>Examples of this application : Disk Mirroring, Disk Encryption, UNIX
>disk I/O monitoring, maybe even compression.

>A picture tells a thousand words:

>NORMAL DISK        ==============                ==============
> INPUT &     <---- | MY DEVICE  | <------------- | ACTUAL     |
> OUTPUT      ----> | & DRIVER   | -------------> | DISK DRV   |
>                   ==============                ==============

I have done this before, and I have seen other implementations.
I suspect that what you want is a driver interface that looks
programmatically identical to a real disk driver.  If you want the
kernel to be abke to mount this device as a file system, that must
be the case.  Forget streams and just write a new disk driver that
in turn calls on the bdevsw routines to eventually call the real
disk driver.  If you have means to do so, look at OSF's LVM (Logical
Volume Manager) source code or documentation or Mips virtual disk driver.

>I don't want to change the disk device driver, because I don't want to
>have to support all the different types of disks out there!

You shouldn't, and don't need to.  All the implementations I know of
work with unmodified disk drivers.

>At first this seemed like a perfect application for STREAMS, but I
>cannot find enough documentation to clearly indicate that what I need
>to do is possible using STREAMS.

Wrong.  Streams is not the right mechanism to deal with a block device
interface, especially considering the comment about mounted filesystems
above.  Make it a block device driver.
--

 == Mark Warren                      Bull HN Information Systems Inc. ==
 == (508) 294-3171 (FAX 294-3020)    300 Concord Road     MS852A      ==
 == Mark.Warren at bull.com             Billerica, MA 01821              ==



More information about the Comp.unix.sysv386 mailing list