* ron minnich [EMAIL PROTECTED] [031002 06:18]:
On 1 Oct 2003, Eric W. Biederman wrote:
The one pass algorithm of the current config tool, already does
not work 100% of the time, the evidence is some options that do not
work properly if I move them. So we might as well rework the code
On Wed, 1 Oct 2003, ron minnich wrote:
On 1 Oct 2003, Eric W. Biederman wrote:
Greg. This is why the original config tool did this in two passes.
one thing about the new tool, and why I thought we might not need two
passes.
Default works this way for a variable (or should)
On Thu, 2 Oct 2003, Stefan Reinauer wrote:
Is this really closer to optimum than the current default..option
behaviour? I don't really think that even having default ROM_SIZE in
a mainboard config file would cause more mistakes than in the Options.lb
file. But I may be wrong...
I think I may
Greg Watson [EMAIL PROTECTED] writes:
Mark,
Understood. The thing I don't like about Ron's solution is that is relies on an
option effectively having two values simultaneously - a default value and a set
value. Being able to modify both these values independently, then relying on a
side
Hi Ron,
I started looking at building the Via/Epia with the v2, and noticed that your
last snapshot said that the mainboard Config.lb should set the ROM_SIZE to
265K.
Here's a little patch that lets the config python use
'default OPTION value' tag in the Mainboard Config.lb overriding
If my understanding is correct, you want to have an option value that
has a mainboard specific default value, but that can be overridden in
the target configuration file?
If this is the case, then my preference would be to do something like
the following in the mainboard file:
if ~
* Mark Wilkinson [EMAIL PROTECTED] [031001 16:44]:
Here's a little patch that lets the config python use
'default OPTION value' tag in the Mainboard Config.lb overriding the value set
Is that not possible already? I've been using it in some of the opteron
builds since a while...?!?
Stefan
On Wed, 1 Oct 2003, Greg Watson wrote:
If my understanding is correct, you want to have an option value that
has a mainboard specific default value, but that can be overridden in
the target configuration file?
If this is the case, then my preference would be to do something like
the
Mark, that patch is not needed, there is already code in place to do that.
But thanks for the input, we appreciate it.
I'm impressed that you got that all worked out!
thanks!
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
Mark,
Understood. The thing I don't like about Ron's solution is that is
relies on an option effectively having two values simultaneously - a
default value and a set value. Being able to modify both these values
independently, then relying on a side effect to determine the actual
value seems
At 10:20 AM -0600 1/10/03, ron minnich wrote:
On Wed, 1 Oct 2003, Greg Watson wrote:
If my understanding is correct, you want to have an option value that
has a mainboard specific default value, but that can be overridden in
the target configuration file?
If this is the case, then my
On Wed, 1 Oct 2003, Stefan Reinauer wrote:
'default OPTION value' tag in the Mainboard Config.lb overriding the value set
Is that not possible already? I've been using it in some of the opteron
builds since a while...?!?
default was not allowed in mainboard files until I added that patch.
On Wed, 1 Oct 2003, Greg Watson wrote:
The problem is you're relying on obscure behavior of an option.
You're setting (or not setting) an option in the target config file,
then subsequently changing it's default value, then using whichever
happens to override the other. See my reply to
13 matches
Mail list logo
