"Ronald G. Minnich" rminnich@lanl.gov writes:
On 12 Feb 2003, Eric W. Biederman wrote:
Ron. I am going to need to do a branch soon as I do the Hammer port and integrate a small C compiler. And I want to make some clean fixes and remove some of the backwards compatibility cruft, and the linuxbios 1.0 code base is an inappropriate place to target. It should be possible to roll in most of the improvements into the 1.0 codebase, but that will just increase the clutter of the codebase.
OK, but be aware that a person here is doing the PPC port, so we'll need to see how to keep him up-to-date with what you're doing.
I intend to be as public as I can about it, so the LinuxBIOS list should work.
Although the PPC code is mostly C, since the cache-as-ram trick is actually well-supported and working on that architecture.
Yes, which is one of the things that encouraged me to try it.
We don't want to drop too many mainboards off the edge in the long term.
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.
A branch would be a good place to fix up support for multiple south and north bridges.
I have to. Multiple identical northbridges, and southbridges will actually be quite common on the Hammer architecture. I actually have a fix present in the pci code to detect and handle these but I have not currently pushed the code.
What I expect is that initially everything will work in the 1.0 codebase but only a subset will work with the 2.0 codebase. At the same time a goal of the 2.0 codebase is that the infrastructure should be clean enough that we don't have to keep continually modifying it and breaking things when more boards are brought online.
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.
The way I expect developers to work is that they start with a stable release of the core, do a port. And the occasionally update to a later core. And when the code is on an uptodate core submitting code back to the core LinuxBIOS tree.
That roughly seems to fit how Tyson and other embedded guys work, and how I do ports I can support. The problem with submitting code back right now is that the CVS tree is a moving target. And I am very very cautious about importing it into my tree as it may break something, on a port I support.
Eric