Messages in this thread | | | From | "Grant R. Guenther" <> | Subject | Re: Parallel, IEEE 1284, Zip drive | Date | Wed, 10 Apr 1996 22:04:21 -0400 (EDT) |
| |
Alan Cox wrote: > Having hacked on the quickcam kernel driver a bit (mine doesnt lockup now > 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.
In the particular case that I get mail about every day: a printer chained off a ZIP drive, neither really does what people want. You see, the DOS drivers appear to allow you to use both, apparently at the same time: you can safely print a file from the ZIP drive. It works in DOS because the ZIP driver hooks the bios printer vector and serialises access based on it's knowledge of the PPA protocol.
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.
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. The lp driver could do it each write() call (whatever it's called in that driver), ppa could do it at the SCSI command level - since each command sends the 'wake up' codes to the device and idles it again afterward. But there needs to be a bit more logic to decide when it is necessary to allocate such a semaphore - since it depends on the specific combinations of command line parameters passed to each of the drivers. And, of course, this all has to *be* somewhere - presumably in the kernel proper.
-------------------------------------------------------------------------- Grant R. Guenther grant@torque.net --------------------------------------------------------------------------
| |