Remove dvma_malloc/dvma_free; drivers should allocate kernel memory and
use dvma_mapin/dvma_mapout to double map it in DVMA space.
Make the resource map `dvmamap' responsible for all DVMA allocation.
The VM map `physmap' only serves the role of placeholder in the VM system.
allocated, as noticed by Chuck Cranor. In addition to re-arranging
the assignment as suggested by Niklas Hallqvist, check to see if maxproc
is higher than the number of available user PTs. If it is, lower maxproc
to that value, the rationale being that it's much more desirable to have
fork() return EAGAIN than to have your system wedge.
XXX note that root can still raise maxproc with sysctl(2) later. It's
probably worth having further discussion about this issue, but until
everyone has time to think about it, this seems like an acceptable solution
for the time being.
This is a step towards getting the drivers ready for new config.
Clean up namespace, remove several instances of global arrays. Instead,
use a softc to carry state around. Where possible, pass a pointer to
the softc rather than a unit number.
Pointers to hardware and software constructs are now stored per port
in each instance of the softc (one softc per board) rather than indexed
by minor number.
This is a step towards getting the drivers ready for new config.
Clean up namespace, remove several instances of global arrays. Instead,
use a softc to carry state around. Where possible, pass a pointer to the
softc rather than a unit number.
of FIFO overflows on high baud rates.
However, doing so on all 4 ports would cost a whopping 64KB (at 4096 entries
per FIFO) of kernel memory. So, the FIFOs are now allocated at attach time
allowing the size for the keyboard and mouse ports to be reduced (to 128)
which should be adequate for the 1200 baud they use.
- properly do MSG_IN handshaking, so we can actually receive multi-byte msgs.
- do synch negotiation (now that the above works).
- handle disconnects.
There are a few trial-and-error bits at points where the docs I have are
particularly ambiguous about the state of chip and/or SCSI bus.
Things to do:
- more cleanup
- deal with MSG_OUT phase better
- keep some "config reg 3" bits per target (ie. FASTCLK and FASTSCSI).
