"Ronald G. Minnich" rminnich@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