David Campbell (campbell@torque.net)
Wed, 2 Dec 1998 07:34:47 +0800
*snip*
> > 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?
>From a driver porting view, having blocking calls as default is nice since then
you don't need any major modifications.
For non-blocking calls (please give an example where would you use them?) a
simple macro wrapper should fix this.
*bing* AARRRGGG!!!
A simple macro would fail for SMP machines as the situation could arise that
the test says it will not block, the other processor grabs the resource, the
blocking function is called and blocks... (or am I being paranoid again)
The only way out that I can see is two "wrapper entry functions" which either
block or fail immediately. Then the entry function calls the relevant routines.
My five cents worth (Australia stopped circulation of 2 cent coins)
David Campbell
=======================================================
campbell@torque.net
Check http://www.torque.net/parport for all Linux parallel port solutions.
Current project list:
a) Madly fixing up web pages....
b) Maintain Linux ZIP drivers (need to update docs)
c) Create Linux chipset specific parport drivers
Any assistance to clearing this list most welcome
-- 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:18:49 EST