On Fri, 2007-11-30 at 16:57 -0700, Jordan Crouse wrote:
On 30/11/07 15:29 -0800, Steve Isaacs wrote:
Is it a viable solution to have buildrom build a cross-tool chain? Imho: This would be best in order to have repeatable results. Having config options to control the gcc and binutils versions cross-host build repeatability would be improved.
This is exactly the direction I want to avoid going in. We really don't want to be in the business of building a complete development environment. Its just too much complexity for what we will gain from it.
I understand your sentiment and if I try to look at things from your perspective I can agree. However, I've seen it mentioned that it is the desire of the LinuxBIOS project to get more board manufacturer's involved. For that to happen LinuxBIOS cannot be a moving target.
Look at it from a manufacturer's perspective. The environments in which I have worked require a stringent qualification, test and release process in order to better understand what is being released. Once released, products can be in maintenance for years and service contracts typically determine who gets an update and when. During this time build servers can be replaced and tools typically move through several revisions.
Parts we place on our boards go through a strict qualification process and once on the board are not changed unless a severe problem is discovered (reduced risk because of test process), the part is no longer available (low risk because of the qualification process) or the board itself is end-of-life.
The same needs to be true for software. Willy-nilly use of a compiler because it happens to be the latest version introduces variables into the code that increases the test problem. Without rigorous qualification of the new compiler flaws can be introduced into the software that can find their way to the field in tens, hundreds or, for some manufacturer's, thousands of copies. Deployment on these scales cost money, the qualification process costs money. Redeployment can cost even more if one considers the disruption of other projects. In order to protect the bottom line manufacturer's typically avoid these costs unless absolutely necessary. And this does not consider the effect such things can have on the manufacturer's reputation in a competitive world.
The key to keeping these costs low is repeatability. A repeatable process is needed in order to reliably run repeatable tests so that when the results do not repeat, a flaw has been discovered (regression testing). This does not mean that a product needs to be perfect, none are. What I'm trying to convey is that known flaws are easier to deal with than unknown flaws. Workarounds are acceptable in most cases. Workarounds are necessary because of not being able to spend the funds to qualify a new tool or restart a full test cycle. Moving targets break workarounds. Repeatability helps maintain the viability of workarounds.
Back to my point. It boils down to cost and risk is a factor that effects cost. In order for LinuxBIOS to be used instead of a proprietary BIOS it must be shown that LinuxBIOS is a lower risk since direct cost is nearly non-existent. Without a repeatable build process risk remains high. Therefore, I believe that like it or not if you want LinuxBIOS to be widely accepted it must be able to demonstrate repeatability. Proprietary providers recognize this and this is why they tout support and controlled releases and get paid for it. imho: Without this for most LinuxBIOS will remain a hobby.
So, if LinuxBIOS does not want to be in the business of building tools then I suggest a project be found that will provide the tools into which LinuxBIOS can be integrated or visa versa. This way LinuxBIOS can also avoid being in the business of beta testing new tools and focus even more on the business of producing a reliable and repeatable BIOS.
Steve