New device layout, including static and dynamic initializers
Eric W. Biederman
ebiederman at lnxi.com
Tue Jul 22 01:35:01 CEST 2003
ron minnich <rminnich at lanl.gov> writes:
> On 22 Jul 2003, ollie lho wrote:
> > Why do you want to call a SINGLE function in different places with
> > different enum value ? Is there any disadvantage to make each call
> > into it own function ?
I hereby reserve judgment until I see Greg's implementation.
I think I am going to complain but I think there is a lot we
can work with as well.
> The problem is, are the three functions defined sufficient? how many
> should there be? What if hardwaremain changes and we add new "passes", do
> we have to add some new set of functions? If we add new passes, how do we
> go about fixing all the parts that we have written code for?
It is trivial to simply add another function to a table of
function pointers if you have something appropriate.
Experience tells me specific functions will do a better job
than a pass argument. But it in the big picture it doesn't much
matter. It is which hooks you have that matter.
Adding entry points is not a problem. I added the enable function
to the device side of things and everything that didn't care
As far as I am concerned the real debate begins when I get
back and can sink my teeth into Greg's code.
For the rest who haven't looked so closely.
Greg and Ron are taking the existing superio model and generalizing it.
I have taken the existing pci device model and generalized it.
And now we have the design review/fight/slug out as we meet in
I suspect the union of the two sets of functions from struct
device_operations and from the superio side is two high. But the way
forward is to get that union and have everyone understand the pieces
backwards and forwards.
More information about the coreboot