[Haifux] Implementing read() like UNIX guys like it
emild at cs.technion.ac.il
emild at cs.technion.ac.il
Sat Apr 23 11:36:12 MSD 2011
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
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. :)
> Web: http://www.billauer.co.il
> Haifux mailing list
> Haifux at haifux.org
More information about the Haifux