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

[Muli Ben-Yehuda]

On Fri, Apr 22, 2011 at 01:31:02PM +0300, Eli Billauer wrote:

> The overall package I'm working on is kind-of general purpose, and
> it's the package's user who chooses how the hardware input behaves.
> I can't know anything about the data flow behavior, and still, I
> want the reads from the relevant file descriptor to behave as one
> would expect. For example, a user may choose to read from the file
> descriptor with scanf or fgets. The user would expect these to
> return whenever sufficient data has been fed into the hardware side.
> On the other hand, if the data comes slowly into hardware, read()'s
> will return with one byte at a time, which is maybe not desirable
> either.

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