Re: [PARPORT] Re: IEEE-1284

Tim Waugh (
Tue, 1 Dec 1998 19:09:15 +0000 (GMT)

On Tue, 1 Dec 1998, ROGER SCHREITER, TEL. XX49 711 685-3891 wrote:

> it's great, that there is movement in parport_ieee1284.c now -
> accordingly to the actual demand of people.

This won't hold up 2.2.0 though. That's not to say we can't sneak it into
2.2.x later on by stealth..

> What does your "attempt at an implementation of IEEE-1284" mean
> for me and the things, we "talked" about some weeks ago?

I wanted to implement a blocking-only interface so that it could be
compared and contrasted to your blocking-or-non-blocking code.

When I looked at your patch, I'm afraid I was a bit put off by pages of
macros. It's quite intimidating to see, and the code that ends up in the
kernel _must_ be maintainable to be useful. I thought that the code might
be simpler (and so easier to maintain) if it didn't have all the state
machines, and so I wrote some code to see.

Note: I'm not against non-blocking calls, but I would like to see code
that's easy to understand.

Another way of doing the implementation would be to have table-driven
state machines, and I'd be quite interested in seeing what the code for
that would look like. IEEE-1284 basically describes a state machine,
after all.

> The new fields and structs in parport.h are fine and are very
> similar to those, I suggested in my proposal for parport_ieee1284 -

Yes, they are, and that's not much of an accident. I started from your
parport_ieee1284.c. ;-)

> Or would you prefer, if I take your code, leave it mostly untouched,
> and just append my non-blocking version as separate thing at the end
> of parport_ieee1284.c?

I think that if a call can be made to function without blocking, the
implementation had better be non-blocking, with a wrapper to make it block
in the blocking case. I don't think it's a good idea to have
implementations for both.

So, we'd better decide if having non-blocking calls is worth the code
complexity. My vote, at the moment, is no. What do other people think?


-- 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:18:49 EST