Nonblocking UART driver using _write_r - error if no data was written?

[Freddie Chopin]

W dniu 2014-02-26 12:30, MikuslawProxy pisze:
> I was wandering if I should ask on you website first, but I see that
> it came to the same thing.

(;

> As for the clue of discussion: I use open(...) without flags to open
> the device. I do it using the _open_r stub as it was described on
> different websites - _open_r redirects the open call to specific
> device open() call. I'm under the impression that if I use it this
> way, the O_NONBLOCK flag would have to be interpreted by my driver,
> not the newlib, so if I'm running always in nonblocking mode it will
> not change anything.
> The fopen call could change something, but in newlib code in version
> 2.1.0 only references I see to NONBLOCK are in mq_open code etc.
> Nothing that seems to touch normal stdin/stdout.

Good point. If newlib does not store any specific flag that marks the 
stream as non-blocking then indeed this makes no difference in your case.

> I think that a question I start to ask myself is if newlib is even
> capable of flushing to nonblocking device. Also, what is the rationale
> behind doing (fflush.c:193):

I guess some rationale is here:

http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html

> When attempting to write to a file descriptor (other than a pipe or
> FIFO) that supports non-blocking writes and cannot accept the data
> immediately:
>
>[...]
>
> If the O_NONBLOCK flag is set, write() shall not block the thread. If
> some data can be written without blocking the thread, write() shall
> write what it can and return the number of bytes written. Otherwise,
> it shall return -1 and set errno to [EAGAIN].

In your case "no data can be written", so the functions return -1. I've 
recently thought about write()/read() implementations in POSIX and I'm 
under impression that 0 can be returned only if you request a write of 0 
bytes. If you request to write anything, the only possible return values 
are -1 if nothing was written (errno set to EAGAIN) or a positive value 
with number of bytes written (I'm not considering any actual errors to 
make it simpler).

Regards,
FCh