> > Does anyone have comments about this, or should I `just do it', as a
> > proof of concept?
> 
> I think this is a neat idea!

I agree; i'm one of the people who's been quietly pushing it (in
various forms)...

> For maintaining source compatibility you can also use MACROs
> or __inline__ routines to isolate machine dependencies
> instead of millicode.

The problem is unfortunately uglier than this, even for things as
simple and common as LANCE ethernet drivers.

Consider the case of a machine such as the Amiga.  The Amiga has a
'native' LANCE ethernet controller.  It can also have an ISA bus
bridge board, and use ISA cards.  Imagine you want to use both a
native controller and you also want to use an ISA board.  They would
have different methods of accessing the board's controllers, different
methods of handling DMA, etc.  If done properly, the
"machine-independent" back end could handle this.  (Note that things
like probing for the device and attachment (including interrupt
handler attachment) would be handled by the front end or a call into
the front end.

Also consider the case of _two different_ ISA ethernet boards, each
using a LANCE ethernet controller.  They will both have slightly
different tweaks for addressing the chip, addressing the shared memory
(or using DMA), etc.  Again, a "machine-independent" back end should
be able to handle this, if done right.  (In fact, it would be very bad
if it couldn't, because it's not unreasonable to expect that situation
to occur.)

> If the MI/MD interface is very fat (lots of little
> routines), it becomes very hard for a new person to
> understand it well enough.  The MI/MD `cut' needs to be
> carefully chosen to make the interface easy to grasp.

The point of Charles's notion of "millicode" (which reminds me of the
HPPA and therefore makes me a bit queasy 8-) is that the interface
could be as wide as a particular driver required.

As you note, having too wide an interface means that nobody (except
perhaps its author 8-) will be to use it effectively.

However, each "machine-indepedent" driver back-end would need its own
set of 'millicode' -- if your common access pattern is to write 4
registers at a time in a specific order, what are the odds that any
other driver is going to need to do exactly the same thing.


You'll note that I keep quoting "machine-independent."  I think it's
better to call them "machine and bus and ..." independent drivers, but
that's too long and is the same to a 0th order approximation.  8-)



chris