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
--
Web: http://www.billauer.co.il
_______________________________________________
Haifux mailing list
[email protected]
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
