> > but it's silly and annoying to have
> > to do a bunch of the same work 2x
> 
> The main part of the work and the advantage from the technical
> point of view is the unified handling of the keyboard controller
> in pckbc.c. (You might find it horribly overdesigned. It's quite
> a lot of code for 2 8-bit ports -- that's what one gets if he uses
> badly designed hardware.) I had done this before for your
> wscons code to look a bit nicer before I've given it to Juergen.
> The remainder is glue code, not really a challenge.

That's a nice advantage, but the existing code tends to _work_ where
it's already being used.  This provides no other advantages, where it
should be able to provide _some_, e.g. uniform handling of keyboard
translation tables (why should each port's pccons.c have to have its
own translation tables, etc.?).

I guess I understand why there are still MD pms bits for the i386
port: you want other ports to be able to provide different MD bits
(e.g. to glue it to a "console" framework like wscons).  However, I
see the i386 port's bits being duplicated to most of the ports which
currently use a pms driver...  (same with the output side of pccons,
for that matter, but if you want to fix that you might as well migrate
to a new, better console/emulation framework... 8-)


> And nobody has the hardware to test a piece of code which
> is critical (as the keyboard controller) on all platforms.

I suppose, but it's not clear that this code really helps that
problem (if you're looking at it with an eye to plugging wscons in,
anyway).  wscons wants a different interface to the keyboard than this
provides (e.g. key repeat), and while that code really doesn't touch
the _hardware_, it still would need to be tested on all ports.

I suppose if the goal is to make these changes only as a temporary
solution, assuming that they'd go away eventually, that could be OK.
If it's meant to stay forever... it adds a layer of complexity where
one doesn't belong.



cgd