ollie lho <[EMAIL PROTECTED]> writes:

> On Thu, 2002-06-27 at 11:13, Eric W. Biederman wrote:
> > ollie lho <[EMAIL PROTECTED]> writes:
> > 
> > > Something OT, we have southbridge_fixup and mainboard_fixup as general
> > > purpose hooks for HW specific code. Why is there no northbridge_fixup
> > > at all ??
> > 
> > Two reasons I guess.
> > 1) As much as possible we want an archtecture that encourages generic/reusable
> 
> >    code.  And the fixup functions don't inherently do that.
> > 
> 
> I am also wondering why we don't have something in a more OO fashion. 
> For example, we have different "classes" of objects like CPU,
> northbridge, southbridge, mainboard and superio, but we did not
> encapsulate them in anyway (except for superio as we do have struct 
> nsuperio). And we are solving the portability problem with an
> "intendend namespace clash". Would it be better to to put them in
> the same way at least as nsuperio, would that be more generic and
> reusable ??

Right.  That is on the long term wish list.  The big question
is how do we transition to a more OO structure without breaking
lots of code.
  
> > 2) No one has needed one, so it hasn't been implemented.
> > 
> 
> I probably need one to setup clock gen correctly. In the current
> architecture, I have no way to insert the clock gen code without
> effect other non SiS chipset. If we have something I proposed in
> the previous paragraph, this code could be a private method in
> northbridge class.

I agree that we definitely need to get a little more abstracted, but
the transition is the hard part. 

What I have been doing in the interim.  Is I have been calling all of
my extra northbridge, and southbridge functions from mainboard fixup.
At least that allows me to write generic functions without having
to call it from the mainline code.

My thought for some of the more generic things is to have the overal
structure look something like.  

enumerate devices.
assign resources to devices.
initialize devices.

Then to find the devices we have either have a hard coded enumeration
or we look them up by some kind of i.d.  

For the serial ports, and the few other pieces of hardware that were
in the original pc, and have legacy I/O ports we need some amount of
special casing so they show up where legacy drivers look for them.

Eric

Reply via email to