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

[emild at cs.technion.ac.il]

Hi Eli,

Since I don't think that there is a definite answer to your dilemma, I suggest a
common solution to it, which you might not like, but here it goes: implement all
three behaviors and use module parameters to select and configure each mode.
Then you can play and experiment with each of them and decide what's best. I
understand that this might be a waste of time, but I doubt you can find a good
answer otherwise.

                                                         Emil  

Quoting Eli Billauer <eli at billauer.co.il>:

> 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 at haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>