TR : LIBIO question

Etienne Fortin etienne.fortin at sensio.tv
Wed Sep 15 18:13:54 UTC 2004



-----Message d'origine-----
De : Etienne Fortin [mailto:etienne.fortin at sensio.tv] 
Envoyé : 15 septembre, 2004 14:13
À : 'joel.sherrill at OARcorp.com'
Objet : RE : LIBIO question


I did't explain my "problem" properly.

There's only ONE fwrite call. But the call is cut in two parts. There's
two calls to the driver, one with 8 bytes and another with 2 bytes,
which account for the 10 bytes asked for in the call to fwrite. For
simplicity, I said that it was "5-5". 

RTEMS is breaking this 10 bytes into two calls to the driver, not my
application. The question remains: is there a way, at the driver point
of view, to know that the total number of bytes that are to be sent is
10 while sending the first chunk (first 8 bytes).

Etienne Fortin
Sensio


-----Message d'origine-----
De : Joel Sherrill <joel at OARcorp.com> [mailto:joel.sherrill at OARcorp.com]

Envoyé : 15 septembre, 2004 14:08
À : Etienne Fortin
Cc : rtems-users at rtems.com
Objet : Re: LIBIO question


Etienne Fortin wrote:
> Hi there,
> Let's say I have the following line of code somewhere in my App:
> 
> 	fwrite(fd, 1, 10, buf);
> 
> Let's say also that the 10 bytes to send are divided into 2 write to
> the driver, each of 5 bytes. The driver will then be called 2 times 
> with a buffer of size 5 each time.
> 
> Question: At the first call to the driver's write function with the 5
> first bytes, is there a way to know that there's still 5 other bytes 
> waiting in the queue to be sent and that the write function will be 
> called again?

Until the application makes the 2nd fwrite call, they do not exist from
the driver's or libio's perspective.  They are not in any buffering
subsystem and thus cannot be expected.

> Etienne Fortin
> Sensio
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985





More information about the users mailing list