[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
TR : LIBIO question
- Date: Wed, 15 Sep 2004 14:13:54 -0400
- From: etienne.fortin at sensio.tv (Etienne Fortin)
- Subject: TR : LIBIO question
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).
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
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