Martin Husemann wrote: 
>> I believe the appropriate way to address that
>>is by adding a way for an aware application to get notice that an
>>error has been detected
> 
> I would do a kqueue event on the /dev/rmidi* file descriptor to notify
> userland of changes (see kqueue(2), kfilter_register(9), knote(9)) and
> provide an ioctl (if that is not already there) to retrieve stats/errors.

That makes good sense to me. It seems a new filter type would have to
be registered, as we don't seem to have one for reporting an error
condition on a fdesc? That seems strange...  I thought about queueing
a read event with EV_ERROR in flags, but that seems to be what kevent(2)
does when it can't handle the request, so that's out.

I was also tempted to handle error detection as an "exceptional condition"
for select(2) or with POLLERR for poll(2) - SUS leaves both up for
definition per device type - but it seems our select is built on top
of <foo>poll() with a fixed mapping of POLLERR to {readable,writable}
and not to {except}; the only thing mapped to {except}, IIUC, is POLLRDBAND.
So if I use POLLERR I can say what I mean with poll(), but I'm not saying
what I mean with select(), and I could say what I mean with select()
only by returning POLLRDBAND, which would not say what I mean with poll().

I wonder if (for general utility) we should define an extra flag bit
that a <foo>poll() routine can return, say POLLSELEXCEPT, that would
be mapped to exceptional-condition by select() and masked off by poll(),
so a driver could better control what gets returned by both syscalls.

Back to midi, for the ioctl idea (as we are aiming for some level of
ABI compatibility with OSS), I would need to pick an ioctl cookie
distinct from anything OSS might introduce. I'm not quite sure what
our conventions are for doing that.

-Chap