Re: Simple resource synchronisation

Albert Cahalan (albert@ccs.neu.edu)
Fri, 12 Apr 1996 10:18:30 -0400 (EDT)

> I guess I should say a bit more about what I mean about
> synchronising access to chained parallel port devices.
>
> Consider a printer attached to a ZIP drive attached to the only parallel
> port in a system. There needs to be a mechanism to allow both the lp
> and ppa drivers to access that port so that one could print
> a file from the ZIP drive, for instance.
>
> The simplest solution would be to use semaphores. In some appropriate
> place deep in the kernel, we could allocate a semaphore for each of the
> parallel ports and fix each of the drivers to 'down' the semaphore before
> accessing the port and to 'up' it when the port is back in a state
> where a different driver could use it. In the ppa driver, for instance,
> the semaphore operations would bracket each SCSI command. Similar changes
> could be made to the lp driver.
>
> Note that interrupts can only be enabled while some driver owns the port,
> and by implication a driver shouldn't up the semaphore if any interrupts
> are pending.
>
> I'm not happy with this solution, because it requires the MUTEX semaphores
> to be pre-allocated for each of the ports that one might want to access
> this way. And, it is conceivable that someone will come out with a
> parallel port that does not sit at one of the standard addresses.
>
> Now there's another wrinkle. I can think of some good reasons
> why one might want to chain a PLIP connection off the back of a ZIP
> drive. PLIP would want to "own" the ports whenever the other driver
> didn't need them, so some sort of preemption is needed, as well.

What about this:

---
There is a driver that provides access to the parallel port.
Right now it would be just one, but EPP and such could be done.


There is an lp driver that uses parallel port access.


There is also a PLIP driver that uses parallel port access.


The Zip driver uses _and_ provides parallel port access.
This lets you chain several together.

---


It means that the lp driver might really be using a service provided
by the Zip driver.  It means you could even tunnel parallel ports
through something completely unrelated.  It means you could have a
driver that would do something to the data stream.  It means you could
redirect /dev/lp0 into the bitbucket, log it, or whatever.


I would imagine that the drivers would pass an int32 that represents
the state of the pins on the port. Perhaps a mask could be passed to
indicate what pins can not be set with the current chain of hardware.