There are roughly a gazillion different instances of the driver for the
mc146818.  This annoys me. :-)

I want to clean this up a bit, by introducing some MI drivers.  There
are a couple of challenges to this:

The first challenge is that the various ports have very slightly
different behaviors with respect to this chip.  For example, some ports
use a binary clock, some use BCD.  Some ports have different year
offsets.  A few ports enable either periodic interrupts or the square
wave output.

The list of possible "attributes" a port might declare are

    12 hour clock (not aware of any that do this)  (boolean)
    square wave enable (boolean)
    binary or bcd clock switch (two values, boolean?)
    periodic interrupt enable
    periodic interrupt rate (8-bit value plugged into register)
    year0 base offset

There are other values, but these are the only ones likely to be used by
a port.  Also, some ports enable/disable interrupts to calibrate their
cpu clocks.  This is done only early in the boot flow.

In particular, the binary clock and year0 base offset don't have good
"default values".   To make truly independent drivers, the only options
I can think of are:

    a) config(1) options, which means that nearly every port that uses
an mc146818 clock -- about half of them -- would need new entries added
to kernel configs (or maybe std.${mach} files.)

    b) "properties" setup via device register.  seems kinda painful to
me though.

    c) an #if #else #endif table describing the defaults for each port. 
This is particularly 'unclean' in my opinion.

The second challenge is the wide and inconsistent use of the mcclock
name, and the fact that mc146818 is a global "attribute" rather than a
driver name.  It makes it very hard to create a new "mcclock" driver
definition (e.g. to add in conf/files, or dev/isa/files.isa), or even
mcclock_isa.c files, without impacting a huge number of ports.  There
are probably around 2 dozen ports which would be impacted this way, and,
quite frankly, I don't want to have to break and fix them all at once. 
I'm still black and blue from com(4).

The possible solutions I see to this are:

    a) create a new MI driver name, "mcrtc", and gradually convert ports
from MD "mcclock" to MI "mcrtc".  Apart from the name changing, this has
the least pain and suffering for me.

    b) add MI drivers to the MI directories, but only list them in
arch-specific files.${mach} -- i.e. leave the config machinery MD.  This
strikes me as particularly messy, although eventually, once no more
ports have MD mcclock code, we could centralize it.  I don't want to
hold my breath.

    c) rename/hack all the ports to use some different name ("omcclock"
was suggested by one developer).  I _hate_ this idea.  I don't want to
touch 8 bazillion different ports unless it is to convert them one at a
time properly.

    d) Give up trying to create MI code, and let the pasteware remain as is.

As far as I'm concerned, I only really think options "a" and "d" are
interesting to me.  Option "b" just seems to much like a short term hack
that will probably live forever, and  I have not the time, energy, or
interest to rototill a few dozen ports all at once.  A gradual change
(where maybe some portmasters or other people can help out!) is much
more desirable to me.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191