[Haifux] Implementing read() like UNIX guys like it

[Eli Billauer]

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