- fix compilation problem for !NFSSERVER && NFS.
  pointed by Tom Spindler on source-changes@.
- make nfs_srvdesc_pool static.
Use macro defined in <dev/ic/i8259reg.h>. Same binaries are generated.
Sprinkle static, pass lib, warns=4
UVM_MAPFLAG: add missing parens.
Do not warn that Ultra160 controllers are limited to 80MB/s. My AHA 29160
works in the Ultra160 mode:

ahc0 at pci0 dev 6 function 0: Adaptec 29160 Ultra160 SCSI adapter
ahc0: interrupting at eb164 irq 0
ahc0: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
scsibus1 at ahc0: 16 targets, 8 luns per target
sd1 at scsibus1 target 0 lun 0: <SEAGATE, ST336607LW, 0007> disk fixed
sd1: sync (12.50ns offset 63), 16-bit (160.000MB/s) transfers, tagged queueing
sd2 at scsibus1 target 8 lun 0: <SEAGATE, ST336607LW, 0007> disk fixed
sd2: sync (12.50ns offset 63), 16-bit (160.000MB/s) transfers, tagged queueing

(Those two drives can read at a speed of 64 MB/s each, in parallel.)

Bump date.
Coverity CID 3147: Plug memory leak.
Coverity CI D3758: Plug memory leak.
Initial commit of new midi.4, pre-wizd.
Now with all .Xr values fully qualified. This still seems awkward to me
but is required for maximum wizd(8) compatibility, and the alternative
of using .Fn selects the wrong font, which looks even worse.
Now for Phase One. The patches to be applied in sequence were created
and tested against 2.0 sources. To begin, let CVS roll the affected files
back to that historic state. The reverse operation will be used (and
will involve some manual merging) after the patches have been applied.
Naturally, intermediate stages on this branch will not be directly
compilable (unless merged into a 2.0 checkout).
Applies fuzz-free to 2.0 sources; adds support for Midiman Midisport 2x4.
Had output and input working in 1.6.2, but managed to lose input in
adapting the patch to 2.0.  Now it's back.  TODO: find out if there's
a way to improve input response (size of simultaneous chords that can
be played without dropping data) - perhaps by increasing the size of
the endpoint's xfer buffer, or learning something more about the usb
interrupt transfers.
Changing the input logic to use wMaxPacketSize transfers instead of
4 bytes may have nailed the input data loss problem; it seems rock
solid now. This patch is against 2.0 sources but there's been so
little CVS activity on those files it should be easy to apply.
Replaces the state machine in midi.c with a full, pedantically correct,
error detecting one. Rearranges some DPRINTFN debug levels to make it
easier to get the level of debug information wanted. Applies to 2.0.
Fixes a bug in midi_unit_count.

Dropped byte and message counters now use evcnt.

My state machine could treat an invalid SystemCommon message or out-of-
sequence EndSysex (all protocol errors anyway) as /mishandled/ protocol
errors if encountered in certain states. Fixed.
Take open modes seriously: do not write if not open for writing, or read
if not open for reading, or if the midi device cannot read. In sequencer,
open only the midi devices that support at least one of the open modes
wanted; so, if the sequencer is opened for reading only, do not bother
opening midi devices that cannot input. Do not write anything to the
midi devices if opened for reading only; seq_reset previously wrote a
bunch of initial settings, which could lead to long timeouts in seq_drain
on close because of data in the output buffer that could not go anywhere.

TODO: sending initial settings is the less important thing for seq_reset
to do; the most important is to reset the buffers so the playing stops!
At present, it doesn't do that at all.
Implement Active Sense on transmit. The same callout used by
midi_start_output for brief delays in output is now also scheduled
for 285 ms if there is nothing to transmit, and will send an Active Sense
at that time if there is nothing else to go; this will keep the receiving
equipment expecting our Active Sense and ensure that notes will stop
sounding when it ceases (either because we close normally, or we hang,
or someone trips over a cable). Sounds simple enough but involved a new
locking strategy, because we used to block out user_incurred start_output
whenever the device interrupt or callout was pending, but in the case of
the 285ms callout we /want/ to let a user write through and cancel the
callout (and avoid races, etc).  Also moved the callout_init into
midi_attach because midiattach was not called in all cases, and added
a callout_stop in detach (though it is not yet quite up to all cases where
the callout may have been fired but not yet run at the time of detach -
nothing is easy.)

Surprisingly, the Active Sense works almost right over umidi: umidi's
state machine isn't smart enough to pass it through a packet being built,
and makes garbage instead, but a Yamaha keyboard at least is happy to
accept a bit of garbage within 300 ms as a sign we're still alive. :)

Now to go do a better state machine for output. :/  It shouldn't be in
umidi; it should be in midi, done once and done right; there should be
no need to have slightly different replicas of the midi state machine
all over the kernel ... I think there's one in sequencer too.
Receive dfa factored out and made usable for both receive and transmit.
So far so good.  Now to rewire transmit to use it.
The DFA (well, technically it's really a FST - a DFA with output) is now
used for transmit as well as receive; it's run at the upstream end of
each pipe (the receive interrupt for receive, the write call for transmit)
so that protocol errors can be detected as soon as possible, and erroneous
data won't fill the buffer. Implemented a guarantee that read(2) on the
raw device returns as many complete messages as will fit in the read
request, so the user program does not have to parse around read boundaries
(except for SysEx). Required a new buffer scheme that preserves message
boundaries. (A little like reinventing STREAMS, hmm...) Implemented
FIONREAD. New approach to sharing the cpu during output to interrupt-
challenged devices.

umidi happens to work now even in the presence of Active Sense, as the
transmit FST ensures the Active Sense doesn't appear in the midst of
another message, and right now the FST is always in canonicalizing mode
so there is no running status to disturb. That's half accident though, and
doesn't work for midisyn (which treats any System Common message as SysEx,
argh). The right solution will be to allow message-based drivers like umidi
and midisyn to get their data via a message-at-a-time interface, rather
than splitting the messages into bytes for lower drivers to reassemble
wrong.
Added hw_if_ext for hw drivers that want their messages intact rather than
byte by byte. Works with midisyn - must still integrate and test with
umidi.