On Tue, 19 Sep 2000, Steve Woodford wrote:

> On Mon, 18 Sep 2000, Bill Studenmund wrote:
> 
> > Please don't do it this way. :-) Just move everyone to a better MI
> > interface. :-)
> 
> In an ideal world, that's what I'd do. :-)
> 
> Unfortunately most ports use the code for their console and I have no way
> to test it on anything but mvme68k. I phear the brickage which would ensue
> should I screw it up. ;-}

Then 1) tell them what you're doing and put changes up for review, and 2)
take solace in the fact that you probably aren't messing with the console
code. The suggestion I made would only be tweaking HOW the MI layers call
the MD routines. The MD routines would stay just as they are now. :-)

Note: I'll be real happy when you do this (regardless of how you do it) as
I've owed folks NuBus serial support, which will be easy after you make
this split, and the Alpha 8200 will work better too as it has two
different styles of 8530 attachments on its motherboard.

> > I'd recomend doing something a little different. Add a pointer to a table
> > of functions to either the zsc or channlestate structures (which ever
> > makes more sense). Then have the zsc attachment just fill this in. As all
> > of the zsc attachment is done in MD (or bus dependent) code, you won't
> > need to do anything in the MI code.
> 
> This is one avenue I considered, and it is the most portable way. I'm just
> not sure our older platforms could stand the performance hit of 
> indirecting through a function pointer for every register read/write...
> (Which is actually a double indirection, since the table pointer needs to
> be fetched first. I guess the compiler's optimiser would help here :)

Well, to save double-indirection, we could add all these routines to
probably the channel state struct, rather than indirecting through a
table. It's not like we'll have too many copies of this data.

But if you have two different attachments on a machine, you either need
different access routines or you need an MI routine which can do
everything. My vote is for the former, your vote is for the latter.
Question to everyone else: what do you thing?

Actually, let's take a step back. You want to get rid of
machine/z8530var.h (which is probably a good thing). A lot of things have
changed in how we do kernels from when this was added, so we can probably
do things a little differently now.

This file contains two sets of things. One is the machine-dependent
extentions (like support for the mac's external clocks). The other is the
prototypes for the access routines. I _think_ that if we moved the
prototypes out of this file and into z8530sc.h that the MI parts of the
code wouldn't need it any more. Well, the few other things needed (should
we call the mdioctl routine or should we call the setclock routine) can be
defopted - something which didn't exist when this file was first made. :-)

That still leaves us with what to do with two different types of zsc
attachment (mainboard and VME for instance, or obio and NuBus for mac68k).
But getting rid of machine/z8530var.h makes it a less-interfeering thing -
the ports that need it can adjust and the others can stay as-is.

One way to re-phrase what you suggested is to add those MI routines you
mentioned, and have them in a seperate (MI) .c file. Then ports which have
multiple types of attachments could use that .c file rather than whatever
they have now. You'd also need a .h file to go with it to extend the
channel state structure to contain the info the MI routines need (which
would be bus_space info among other things). Actually we could just shove
the bus_space info into the channel state structure, and ignore it on
machines which don't use it.

How is this different than what you suggested? The word BROKEN dosen't
appear. :-) We standardize the interface to something we all agree is the
right thing. :-) Also, you were concerned about impacting other ports and
possibly breaking them. I think this path would get us the improvements
you wanted w/o breaking other ports (as you haven't changed those
routines, just where their prototypes are). The different port masters
still have to switch to using this new .c rather than whatever they have
now. :-)

Hmmm. As I sit here, I'm not sure if it wouldn't be better to just have
the one MI routine you suggested...

Take care,

Bill