[LinuxBIOS] Infamous __stack_chk_fail problem.

[Jordan Crouse]

On 03/12/07 08:34 -0800, Steve Isaacs wrote:
> 
> 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.

You don't have to worry - as you can infer from the e-mail address, I am
keenly aware of the challenges that we have to face for commercial adoption.
It is one of my primary goals to ensure that LinuxBIOS becomes and stays
a viable option for commercial vendors.  

That said, you have to understand that LinuxBIOS and Linux and indeed
all of open source will continue to constantly be a moving target.  
Every day the open source environment presents us with a slightly different
view of the world as it twists and turns and evolves.

When I write code, I imagine that every open source project is a train,
constantly rolling toward an unknown destination.  At every stop, new
people are introduced to the project and get on board.  They may have
heard about the project at a conference, or on a slashdot posting, or
just stumbled across it on freshmeat.  However they got here, something
compelled them to board the train.  Whats more, they are going to
bring some sort of baggage with them - different distributions (or even
operating systems), different languages, and different experiences.

Our job is to make sure that every new person that boards the train is
immediately satisfied; because their first perceptions of the code 
are what determines if they stay or if they immediately get off the train.

This is why we need to make sure that LinuxBIOS works right out of the box
with as many different pieces of "baggage" as possible.  Buildrom is an
excellent tool to help accomplish that, but it can not and should not be
essential for all those new passengers to get satisfaction from their first
LinuxBIOS experience.

Commercial vendors and manufacturers are no exception - every commercial 
project has to jump on the train at some point.  The code is evaluated
and a snapshot of all the current versions, behaviors and bugs in the
code is constructed.  Once the code has been qualified, it is always
wise to freeze the code where it stands, anybody who disagrees obviously
hasn't been in the trenches when trying to bring up a new platform.
I have numerous projects sitting on my desk right now, not a single one
of them that is running kernel version 2.6.24-rcX (heck, none of them are
even running 2.6.23).  

But this doesn't mean that the train doesn't keep on going without us - 
the code continues to evolve and prepare itself for the next new passenger.

This is why we (the project) doesn't want to start dictating terms like
compiler versions and the like.  Once we do that, we start to lose new
users and contributors, as the price for admission starts to go up
(especially as we start ignoring new features and flaws in newer compilers).
Instead, we need to focus our energies on making sure that LinuxBIOS
continues to work for every new passenger that gets on our train, and
that regardless of what point our commercial vendors and friends decide
to freeze, that they'll get the best possible experience from the 
compilers and applications that they have chosen.

All that said, I think its probably time that we fix this problem once
and for all.  Ron and Stefan - you are the remaining "experts" on the
v2 configuration system - how can we sneak in the $(try-option) calls
from buildrom (which were in turned borrowed from the kernel) into LinuxBIOS
to put this thing to bed once and for all?

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.