device driver: cdesw questions?

[Andriy Gapon]

on 21/01/2009 16:05 Robert Watson said the following:
> 
> On Wed, 21 Jan 2009, Andriy Gapon wrote:
>> I also would like the driver to provide a select capability quite
>> similar to that of network (e.g. TCP) sockets using d_poll. I.e. a
>> userland program should be able to query when it can write data to the
>> device without blocking and when it can read data without blocking, plus
>> when an error occurred in the device/driver, so there is no point in
>> further waiting.
>> At this moment I am thoroughly confused by meaning of various event
>> masks described in poll(2).  E.g. what is normal priority, non-zero
>> priority and high priority.
>> Which flags should I care about if all data is the same priority for me?
>> Which flag(s) should I set when I'd like to communicate an error
>> condition (e.g. similar to TCP connection reset)?
> 
> I find that the description of the polling flags is at best confusing in
> both man pages and specifications.  The best bet is to look at the
> existing TCP semantics, which are basically defined in sopoll_generic():
[snip]
> A few observations:
> 
> - Neither POLLHUP nor POLLERR appear to be implemented for sockets (all
>   protocols use sopoll_generic in practice).  This is surprising given the
>   wording in the poll(2) man page.
> 
> - Make sure to distinguish POLLIN and POLLINIGNEOF -- the difference
> between
>   soreadable() and the test in POLLIGNEOF is that POLLIN also considers
>   SBS_CANTRCVMORE (i.e., at least half-close in the receive direction) but
>   POLLIGNEOF doesn't.
> 
> I think Kostik's pointer to the pipe_poll() code is a good one, but if
> you're looking to emulate TCP semantics a bit more exactly, these
> differences should be taken into account.

Robert, Kostik,

thank you for the great pointers.
>From previous network programming I recall that if an error occurs on a
TCP socket then select(2) marks the socket as available for reading (and
probably for writing too), then a subsequent operation gets actual error
code. I think that maybe this was the only way to do it in select-only
days. I am a little bit confused about exceptfds parameter of select,
the manual page says "The only exceptional condition detectable is
out-of-band data received on a socket" and I am not sure what that would
be for TCP and how that could be used in practice.

Anyway, I'd probably stick to the same strategy - mark the device as
available for reading and writing if an error occurs and then return
error code in actual read/write.

-- 
Andriy Gapon