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 <e...@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@haifux.org > http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux > _______________________________________________ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux