On Thu, 23 Aug 2001 16:08:55 +0100, Tim Waugh <twaugh@redhat.com> wrote:
>
> On Thu, Aug 23, 2001 at 10:07:28AM -0400, Dave Strauss wrote:
>
> > This may or may not help, depending on how big the chunks are that get
> > passed into lp. If the application is sending things in small pieces,
> > increasing LP_BUFFER_SIZE isn't going to help much.
>
> Right, and a quick test shows that LPRng (for example) likes to write
> one page at a time. :-(
>
> > Do you mean the "preempt" in the parport device structure? So, lp
> > would claim parport on lp_open(), put it into ecp mode, and leave it
> > both claimed and in ecp mode until lp_release(). Is that what you
> > mean? One problem -- can't the preempt function get called at any
> > time? What if it gets called in the middle of a data transfer (or in
> > the middle of any other lp entrypoint, for that matter)?
>
> The preempt function doesn't have to give up the port right away. It
> can make a note that it should release it 'soon'. Then at the end of
> the entry points, you can check the flag and release the port if
> necessary.
>
> Tim.
> */
>
OK, that could work. Is there any way to lock access to the flag
while I'm testing it and resetting it? What I'm envisioning is
something like:
entrypoint()
{
if (!check_if_we_own_parport()) {
parport_claim_or_block ();
set_ownership_flag();
}
do_stuff();
if (check_release_me_flag()) {
parport_release();
lock_access();
clear_release_me_flag();
unlock_access();
clear_ownership_flag();
}
}
I don't believe we need to lock access for the "ownership flag"
because only one process can have lpx open at a time.
-- Dave Strauss
-- 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 2b29 : Thu Aug 23 2001 - 11:42:20 EDT