Ram initialization and small c.

[Eric W. Biederman]

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On 13 Feb 2003, Eric W. Biederman wrote:
> 
> > Agreed. But at the same time our code base is such that hardwaremain()
> > is not as fixed as it should be.  Which means that without great care
> > things break.  
> 
> I'm assuming hardwaremain is dead, although I will be sorry to see our 
> very first linuxbios message go in the ashbin of history. :-)

Actually my intention is to simplify it and make it architectural neutral.

The basic layout I am looking at, is to have some kind of list of hardware
in the code.  And then for each piece of hardware call an initialization
function.  This has the potential to replace a lot of code in the
current hardwaremain.c  Handling initialization order is an
interesting problem I have not tackled yet.

There is some prototyping of that in the p4dpr, build for this.  I
just have not taken advantage of it yet.  

> > Ron I don't know how to manage it but we need to setup a system where
> > we have releases of the core codebase.   And one of the tasks of
> > doing a release need to be to review the changes that went in since
> > the last release so we can avoid things like a broken intel_chip_post
> > macro.  Having code like that temporarily in CVS is fine.  In the core
> > that is a pain.
> 
> absolutely. Here is where my experience falls short. Do you have (or does 
> anyone have) experience with managing this sort of thing? 
> 
> I agree that the tree has been moving pretty quickly. I would request the 
> committers to use the RFC process to this list before making far-reaching 
> changes. Any change that involves .inc or .S files is far-reaching, no 
> matter how small it looks.

A little bit, and Ken Yap of etherboot does a good job, so it may be worth
looking at what he is doing and emulate that to some extent.

Basically one person is the release manager (usually the maintainer of
the project).  And that person makes the final decision when a release
is ready.  Bumps the version number, tags CVS and puts out a tarball
with all of the code as of that release. 

One of the things I do with releases at Linux Networx, is I always make
a diff against the last release.  Review it.  And make certain I know
what all of the code in there is for.  And I worry more about generic
code that affects everyone.  And less about what an happens on an
individual board.  And stable releases are different from development
releases.  For development releases a things breaking is expected.
For stable releases the level of care and conservatism must go up.

Which is while I figure it is time to start a development version of
LinuxBIOS so I can twist turn and break things.  The 1.0.x series can
stay around supporting everything we do now.  The 1.2.x or 2.0.x
series will handle all new things.  And if a motherboard has an active
maintainer.  The code can be moved to the new codebase.  If not we can
just drop that port from the latest version of the tree.

But dropping ports and breaking ports by design should only happen on
major versions of LinuxBIOS.  And new major versions should come very
seldom.  As our abstraction layer gets better there are fewer and
fewer reasons to break an existing port. 

But there are a lot of dead experimental features whose time has
come to be dropped.  Non ELF booting. northbridge_fixup,
southbridge_fixup, etc calls in hardwaremain.  Which are just not
generic enough.  Some of the old pci calls.  The etherboot built into
LinuxBIOS, etc.

Every project is different and things work out differently.  By
dropping the code in a development release and still supporting it in
the last stable release things should get a lot better.

Eric