Re: [hpoj-devel] Forking of ptal-printd

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

Timothy Lee wrote:
> Yes, I think you can exit upon failing to create the pipe.  As for the
> other run-time conditions you mentioned, here are my suggestions:
> 
>    * Failure to open the pipe / failure on select () ---- Just discard
>      the data
>    * Failure to open peripheral ---- can ieee12844pp.o force ieee12844.o
>      to re-scan for new peripherals???  If not, I'd say discard the data
Once ieee12844pp is successfully loaded, a rescan actually happens each time
an application tries to open a service on the peripheral if no other
application currently has any open channels, which is usually the case
since currently there are reliability problems otherwise.  :-)

>    * Failure to write data to the peripheral ---- maybe a retry
>      threshold, after which data are discarded?
It might make sense to retry the remainder of a partial write (which would
probably be best located in PTAL itself rather than in each application).
I don't think there's any point in retrying a completely failed write.

> One more thing, about the ieee12844.c and ieee12844pp.c:  the static
> variable *debug* should be initialized to 0.  Most end-users probably
> don't want to see messages popping up on their consoles.....  <grin>
I did make sure to initialize it to 0 when I added it to ieee12844pp.c.
Now that you mentioned it, I noticed that the one in ieee12844.c (in which I
haven't made any code changes of my own anyway) doesn't have an initializer.
I suppose it's a bad assumption that it gets initialized to 0 by default,
but that may be the case anyway since I haven't had any trouble with it.
Have you seen any situations where debugging was turned on by default due to
its being "initialized" to a garbage nonzero value?

David