mike smith wrote:
> 
> > At that point, I'd like
> > to think about doing something like the MI "zs" driver has done.
> 
> I looked at that a little not long back, and TBH I liked it a lot more,
> I just couldn't work the low-level console stuff out.  I should try
> again now that I have a working scancode parser, as that's all the
> driver should _really_ have to be.  More study of the sparc driver
> would be fruitful, I suspect.

Well, I just blew the evening playing with this as an idea.  I'm not
quite so sure I like it, unfortunately.

Firstly, I couldn't actually find an MI "zs" driver, only the one
in the sparc port.  It, and the sparc keyboard driver, are made much
cleaner by virtue of there being a working prom console interface, so
that there's no need for the keyboard driver to be involved with
cngetc() and the like.

In addition to this, the sparc 'kbd' driver uses tty's to talk 
to the upper and lower layers.  That's actually a reasonable
model to pursue, now that itekbdin() basically just stuffs the
character into its tp, but it means that the kbdsw structure
would have to be abandoned or stretched to some degree to deal
with the different means of initialisation required for the 
two interfaces.

Making the apci driver talk up to the keyboard handler, by 
contrast, was pretty easy - this was using the 'pseudo-device dnkbd'
approach, again as per the sparc port.

Perhaps it's something to pursue a little further down the track,
perhaps after you've converted the scsi driver over to use the
MI scsi code?  It'd be nice to be able to use my CDrom on the
425 8)

If you wish, I'll clean up and rename the apkbd driver
(de-cruft it in particular) and post the diffs in a day or two.
 
--
Mike Smith  *BSD hack  Unix hardware collector
The question "why are the fundamental laws of nature mathematical"
invites the trivial response "because we define as fundamental those
laws which are mathematical".  Paul Davies, _The_Mind_of_God_