Re: [hpoj-devel] more code changes

[<pa...@rc...>]

Hi, Tim.

Tim Waugh wrote:
> Gotcha.  You can't reserve IO regions from user space, can you?
> 
> Using /dev/parport0, you can try to get exclusive access to the port,
> which will (a) load parport_lowlevel, and (b) make sure no other
> device drivers can touch it.  But that's for 2.4.x only at the moment.
I may look into this at some point if it becomes necessary, but for now I
want to be as kernel-independent as possible.  Any OS/version-specific
features like this would have to be optional and turned on or off by the
configure script, similar to how I detected and worked around the problem
with including <sys/io.h> in C++ code.

> But for the mean time, yes I think opening /dev/lp0 and keeping it
> open is a 'good enough' way to prevent pulled rugs.  It doesn't stop
> the user from doing 'modprobe -r parport_probe; modprobe
> parport_probe', but the user is supposed to be on your side in this
> application I think.
I agree now that I've thought about it some more.

On a related note, Tim, how familiar are you with using the hardware-assisted
ECP transfer modes (using the FIFOs)?  I attempted to code support for that
into my ParPort class but had trouble getting both forward and reverse ECP
transfers to work.  I'm thinking I may not be turning the bus around
correctly.  For now I'm doing all of the signalling in software, just the way
it was done in ieee12844pp.c, but eventually I'd like to start using the
FIFOs (no DMA or interrupts) to try to improve performance.

David