lkml.org 
[lkml]   [1996]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Parallel, IEEE 1284, Zip drive
Date
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
--------------------------------------------------------------------------


\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.121 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site