Re: [PARPORT] parport driver

Riccardo Facchetti (
Sat, 18 Apr 1998 00:31:49 +0200 (MET DST)

On Fri, 17 Apr 1998, Tim Waugh wrote:

> On Thu, 16 Apr 1998, Riccardo Facchetti wrote:
> > Okay. I have ignored all the problems with port status, port sharing et
> > all. Boh ... we can even write something like ParportSelect() for what it
> > is worth doing so.
> Oh, that reminds me. I don't know if you've looked at ppuser, but it's an
> implementation for /dev/parport0.

No but I am trying to connect torque to download it (it is a bit late now
and finished this e-mail I will go to bed :)

> The current interface feels a little clunky to me, and probably it could
> make use of the interface you described.
> There could be a "setup" ioctl to define what exactly read/write does
> (currently it's only parport_read/write_fifo_block).
> I'm unsure about whether having that would be justified. Thoughts,
> anyone?

Defining the behaviour of read/write with an ioctl interface should not
introduce more confusion in the code.

For me the better way of doing so is to hide behind the "setup" ioctl,
and in a wider point of view, behind the /dev/parport0 operations, a set
of parport_operations (one for every parport mode) that can be switched
with a "setup" ioctl and configured with ioctl and/or /proc filesystem.
One struct parport_operations for every parport kind (and this way I
include parport_8255, parport_ecp, parport_ps2 as well as

But of course this is something to be pondered a lot, for the
performance reasons you have alredy explained.

.... downloaded ppuser ...

Just a fast thought ... ppuser seems something in the direction I think
is the good one, but ... look ... in parport_read/write I see ECP and EPP
modes coded into the same function. Hmm ... not really cosmetic to see :)


-- To unsubscribe, send mail to: --
-- 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:38 EST