Re: Parallel, IEEE 1284, Zip drive

Philip Blundell (phil@tazenda.demon.co.uk)
Fri, 12 Apr 1996 12:05:35 +0100 (BST)


On Wed, 10 Apr 1996, Grant R. Guenther wrote:

> Alan Cox wrote:
> > if the camera falls off - I am happy ;)), I think the problem we have is
> > small. The plip driver,lp, qcam and other devices need only one small
> > change to solve the problem. They need to use check_region/request_region
> > in their open/close routines not at init. That way one driver will
> > block the others cleanly rather than failing to have them all boot politely.
> > Maybe someone with enough weird parallel junk can try making those changes ?
>
> I really don't see how this is any better than the current "official"
> answer: use each of the drivers as a module and load only one at any
> point in time.

I think Alan's solution will do, at least in the interim.

> Users want the same functionality in Linux. And some people are actually
> risking their data and hacking out the request_region code so that they
> can run both drivers simultaneously - relying on their own discipline not
> to mess up.

Shouldn't be too bad. The zip/scsi driver can request_region() before it
does a SCSI command, and free it again afterwards. The lp driver can
claim the port before it's opened, and free it when it closes. This will
lock the ZIP out while the printer is actually in use, but I think that
may be something we have to live with.

> What we need is not difficult to do - it could be as simple as
> associating a semaphore to the shared port structure and requiring each
> driver to wait/signal on the semaphore at the appropriate points in its own
> protocol.

You *could* do that, but there's nowhere obvious for the semaphore to go.
Potentially you could extend the resource manager to give you a
request_shared_region() call that would hand you back a semaphore to use
with that region. And you would have to deal with IRQs somehow as well.

This would work OK with the lp and ppa drivers, I guess. I'm not sure it
would be sensible to drag PLIP into it though; that seems less inherently
shareable, since you can't control when the other machine is going to
start wanting to send you data. I suppose it could be made to work after
a fashion, but it wouldn't be pleasant.

--
.signature: Permission denied