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

[guy keren]

Hi Eli,

i'm afraid you're trying to solve the "holy grail" of non-local files.
you can't hold the pole on both sides.

first - it does not seem that you have a notion of "end of file" for
your input - is there? the only time when read is allowed to return 0,
is when it reached end of file (for a file), or got a connection close
(for a socket or a pipe).

so you first need to decide what constitutes an end of file with your
device.

Now, if you decide that your read will not block indefinitely (which is
against the posix definition, as far as i know) - you'll have a problem
with the following scenario:

the user calls "read", you have some data so you read what you have and
return it to the user.

the user does something with the data, then calls "read" again. there is
no data to receive - so you decide to fail with -EAGAIN. however, the
user did not set the file descriptor to non-blocking mode, so the user
does not expect to get this error code - and thus the user's code may
fail. not good.

so the logical thing will be:

if the user calls "read" and there is data - return what you have to the
user without blocking. if the user calls "read" and there's no data -
block until there is some data - unless the user explicitly set the file
descriptor to non-blocking mode.

the most you can do is write the documentation for your driver, so the
users will know what to expect, and give them code examples to use.

there is another set of questions:

1. is there some kind of protocol in which the data arrives from this
FIFO, or is it just an unrelated stream of octets?

   in the former case - you can return from read() when you've read a 
   "full message".

   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).

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?

--guy

On Fri, 2011-04-22 at 16:29 +0300, Eli Billauer wrote:
> Hi Muli,
> 
> 
> I'll answer the your last question first: What I'm doing is basically a 
> general-purpose connection between a hardware FIFO within an FPGA and a 
> device file in Linux, with PCI Express as the data transport. That's why 
> I don't know if data will be coming constantly or in small drops into 
> the FIFO. I don't know if the user wants to use fread() or similar to 
> read chunks, or fgets()/fscanf() to get records of data.
> 
> 
> And most of all: I want this to work out of the box, even if the 
> programmer and/or user is, how shall I put it, of the less qualified 
> type. The less pitfalls, the better.
> 
> 
> But it's more like a socket, anyhow. Or a pipe.
> 
> 
> And I know about O_NONBLOCK, of course, and I'm going to support it. But 
> that doesn't solve the "less qualified" issue. And still, we're left 
> with the question of whether an O_NONBLOCK call should return zero or 
> some bytes of data when it can't fulfill the entire request. I mean, 
> strictly speaking, O_NONBLOCK only tells the driver not to block, but it 
> doesn't say "give me what you have". Even though I would make the latter 
> interpretation.
> 
> 
>    Eli
> 
> 
> Muli Ben-Yehuda wrote:
> 
> > On Fri, Apr 22, 2011 at 01:31:02PM +0300, Eli Billauer wrote:
> >   
> > There are a couple of ways you could look at it. First, ask yourself
> > is the package user more likely to treat this as a file or a socket?
> > And if a file, is it a structured file or a certain size, or is it a
> > file whose contents are not known in advance? Then make your read
> > behave the same way a read on such a file or socket would behave. I
> > don't like this option, personally, because it makes assumptions about
> > the user.
> >
> > The second way is to just support both modes of operation. Check if
> > you were opened with O_NONBLOCK. If yes, don't ever block -- you are
> > allowed to return -EAGAIN if you would otherwise block. If you were
> > not opened with O_NONBLOCK, then blocking is allowed, and you can wait
> > until you have a full quantum of data to return at once.
> >
> > Just out of curiosity -- what does the hardware do?
> >
> > Cheers,
> > Muli
> >
> >
> >   
> 
>