Alexandre Ratchov wrote:
> i agree here; the only point is whether or not midi apps, will have
> access to active sensing and to aborted messages (nobody should care
> for the latter at least if read(2) doesn't fail)
> 
> i'm understanding your point; As an user-land midi developper i've just
> tryed to friendly present you my personal point of view.

Ah, ok. Something in the tone lost me last time; no problem.

The active sensing we've covered. While write(2) will reject ill-formed
messages(detecting errors nearest the source), read(2) does not fail if
they occur in input (because the application is not in control of that,
and a failure return from read would be handled unpredictably by existing
apps). Counts are maintained though, so problems can be diagnosed.

> yes, i've contributed some midi patches to obsd; i've tried to keep
> compatibility with both NetBSD and Linux (ALSA raw devices pass active

And I think both ALSA and OSS4 have features we will want, and it will
be interesting to see what can be achieved in multi-standard compatibility
within an architecture that keeps a handle on code duplication and can
make nontrivial guarantees to the components above and below midi(4).

> i've no more comments. i'm looking forward for your midi work; feel

The kernel part of the work is in -current now; happy hacking, and do
let me know if you notice things that (within the design goals covered
earlier) can be better.

Thanks for your interest!

Regards,
-Chap