Tim Waugh (tim@cyberelk.demon.co.uk)
Thu, 12 Feb 1998 22:14:43 +0000 (GMT)
On Thu, 7 Aug 1997, Philip Blundell wrote:
> There are a substantial number of devices that plug into parallel ports
> but have user-space rather than kernel-based drivers. It would be nice
> if these could interact with parport, at least in a minimal way. I
> don't expect the full set of parport facilities to be made available to
> user space, because that isn't really appropriate, but I think it would
> be good if there was some way for a user-space task to gain exclusive
> control of a port in the same way that kernel-based drivers can now.
> There would be no need to provide for preemption or lurking, just the
> basic parport_claim() and parport_release() would do.
>
> Is anybody interested in doing this work? I'd like to see it done, but
> I don't really have the time to work on it myself. I don't think it
> would be very difficult.
I've (minimally) implemented this. The way I've done it, you just need a
device major number for a /dev/parport{n}, and away you go: open the
device, issue ioctls for claim, release, read/write status, read/write
control, read/write data, etc.., and set mode (to, for example,
PARPORT_PC_PCEPP or PARPORT_PC_PCEPP). Once an ioctl to set the mode has
been performed, reads from and writes to the device use the appropriate
read_block/write_block parport function.
Opening the device registers a pardevice, and closing it unregisters the
pardevice. The ioctls for writing registers should arguably be replaced
with ones to frob the registers (set bits).
I suppose interrupts could be communicated using select, although that
would be a bit hacky.
What does everyone think about this? Is there a better way it should be
done?
Tim.
*/
-- 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:28 EST