Philip Blundell (Philip.Blundell@pobox.com)
Tue, 14 Apr 1998 22:08:31 +0100
>The actual implementation of parport as lowlevel driver, seems to me
>that lacks in generalization. It is not generic in the way could be.
>The lp driver knows about parport and uses parport registers to drive
>I/O. It should not be this way IMHO.
It is the way it is because we need to balance efficiency with genericity. In
fact the parport interface is fairly abstract - it just happens to present you
with an interface that looks a lot like an 8255 parallel port. :-)
The lp driver doesn't use registers directly. Yes, it contains construct like
`parport_write_data' to write the data register but, in the unlikely event
that you were writing a driver for a port that didn't use an 8-bit register
for the data field, you could implement this as a function to do the necessary
bit twiddling in however many registers your implementation uses.
The only place where lp.c is wrong in this respect at the moment is that it
frobs the control register to turn interrupts on and off, which is a bit
PC-centric.
>a parallel ZIP drive ? Can I print WHILE doing backup on the ZIP ?
Yes. People do.
>Can I add then another device like a Xircom parallel network interface
>and do network+ZIP backup+printing to the printer with all these devices
>attached to the same parallel interface, all at the same time ?
Yes, so long as you can physically attach all the devices.
>ParportRead() and ParportWrite() should do Int/poll and/or DMA as requested
>in ParportSetup(). lp, zip, netifaces, etc should not know about interrupts
That's no good for a lot of devices. It often happens that you have to be
able to bit-bang directly. What you have described would be OK for printers
but we also have to support Zip drives, QuickCams, ethernet adapters, Control-L
buses, EPROM emulators, PLIP links and probably many more devices that don't
speak the standard read/write byte protocol.
>Of course these considerations come from a fresh reading of ECP specs and some
>humbling about actual parport implementation, so it may be totally wrong.
You have to remember that not all the world is ECP. Also, with the current
scheme we get the ability to do port-sharing and make drivers more portable
(eg lp.c can work on several different types of hardware) but without any major
impact on performance -- take a look at a disassembly of lp.o some time. It
would be a loss if you had to go through a generic mid-layer every time you
wanted to write a byte.
p.
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:17:37 EST