At the moment, pckbd(4) and pms(4) can only attach at pckbc(4).  This is a
bit of a nuisance, since some systems (e.g. those supported by
NetBSD/acorn32) have AT keyboards and PS/2 mice handled by other chips.
I'm currently working on building an abstraction layer, but I'd like some
comments from other people on how it will work.

My current plan is that chip drivers like pckbc(4) would export relatively
simple operations for byte transmission and reception, and a new midlayer
would handle actual commands, with all the retries, timeouts and general
unpleasantness that entails.  pckbd(4) and pms(4) would see much the same
interface as at present, but a lot of the code currently in pckbc.c would
move into the midlayer.

Things named for the abstract interface (including dev/pckbc and all the
functions called by pckbd(4) and pms(4)) would be renamed to pckbport*,
leaving "pckbc" to refer just to the i8042-based controller.  This avoids
changes to kernel configuration files.  The replacement for pckbc_tag_t,
pckbport_tag_t, would be a pointer to a structure full of function
pointers for the midlayer's use and a pointer to controller-private data
(eg struct pckbc_internal).

What have I got wrong or forgotten?

-- 
Ben Harris                                                   <bjh21@NetBSD.org>
Portmaster, NetBSD/acorn26           <URL:http://www.NetBSD.org/Ports/acorn26/>