Hello Guy,
guy keren wrote:
first - it does not seem that you have a notion of "end of file" for
your input - is there?
As a matter of fact there is: An extra line (in hardware) will say "no
more data from hardware" which will cause an end of file condition on
the Linux side. This is not mandatory to use, but I figured this could
be a useful feature.
And if we're at it, there will also be a (hardware) line which will be
asserted as long as the file is open on the Linux side, so that some
hardware logic can reset itself between file sessions.
Now, if you decide that your read will not block indefinitely (which is
against the posix definition, as far as i know)
Oh, no. I wouldn't even think about going that far. The issue in
question was not whether to block or not given the lack of data, but
whether to return a partial buffer immediately or to wait until the
requested data count has arrived. Or to wait "a bit" trying to increase
the length of the chunks (as TCP/IP does in order to support both data
and terminal connections).
if the user calls "read" and there is data - return what you have to the
user without blocking.
That is one of the options I considered. The drawback of doing this
exactly like this, is that if data arrives at a slow rate (say, 100
kB/sec) it's likely that every read() operation will yield one byte of
data, making the CPU spin around this instead of doing something useful.
1. is there some kind of protocol in which the data arrives from this
FIFO, or is it just an unrelated stream of octets?
Yes. (That is, the user can do this or that. I can't know in advance).
in the former case - you can return from read() when you've read a
"full message".
Then again, I don't know what's going through the lines.
in the later case - if a user will use fgets() - the user is a
complete fool - since fgets expects to read until end-of-line (and
it blocks until this happens).
As I said, I try to make things work even for "less qualified" programmers.
2. if question 1 is irrelevant - what kind of data does the user get
from this FIFO? does the user control the data that is written into the
FIFO from the hardware - or is it completely not in the user's control?
The user gets a way to connect to the FIFO on the hardware end, and is
free to use it as he likes. Then I want him to be able to open the
device file any way he sees fit, read from it like he sees fit, and the
whole thing should work like a clockwork.
The whole point of this project is to make the communication between the
FPGA and a sophisticated OS really simple (for the user).
Thanks for trying. :)
Eli
--
Web: http://www.billauer.co.il
_______________________________________________
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
