Re: parport patch / lp_readback

Philip Blundell (
Mon, 21 Apr 1997 23:56:18 +0100 (BST)

On Tue, 22 Apr 1997, Carsten Gross wrote:

> My questions are:
> - Have you tested the IRQ driven lp-driver? I think this could be a problem.
> I've added a 'if (LP_IRQ(minor)) return -EINVAL;' to the code. Perhaps
> this is not necessary?

Can you explain why you think it's necessary? Perhaps I'm just being dim.

> - Is "blocking IO" a good choice? This means a read from the device
> with no data available "hangs" (for example the simple 'cat'). If you add
> a 'fcntl(fildes, F_SETFL, O_NONBLOCK)' in an user program, a read from the
> device with no outstanding data returns EAGAIN. At the moment this is my
> choice and this is different to the old version.

I think this would be better, yes. Another thing I'd like to see is being
able to open the device for reading when it's already open for writing, if
that can be made to work without upsetting printing. Often I want to read
back status from the printer to see why it's upset when it stops printing.

The parport code is due for something of a change soon anyway, because it
turns out it isn't sufficiently generic as it stands to make it easy to
implement on multiple architectures. As part of that I'd ideally like to
see the existing lp driver thrown away and completely rewritten, to be