[LinuxBIOS] Infamous __stack_chk_fail problem.

[Steve Isaacs]

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