Re: config -> default

[Greg Watson]

Stefan,

Which builds are broken? I thought I checked all configurations built 
after the change (apart from the VIA which Ron was working on.) and 
modified any that had problems.

My hope was that this change would make the use of options more 
logical and consistent. The intention is that parts set default 
values for any options that they require or are specific to the part. 
Then when all the parts are put together in a target configuration 
file, these default values can be overridden for the specific build. 
I was also toying with the idea of allowing some options to be 
read-only, which I think would address your concern.

Apologies for breaking things. I try to build all targets after any 
change like this to make sure things are still working.

Greg

At 4:16 PM +0100 11/6/03, Stefan Reinauer wrote:
> Hi,
>
> most of the builds are broken again since "config" in the mainboard
> config file now has to be renamed to "default". On the one hand I see
> the reason for most of these changes, even though I am not sure if
> we want to suggest that some stuff can be overridden in the target
> config file, like:
>
> -option CONFIG_IOAPIC=1
> +default CONFIG_IOAPIC=1
>
> Can those changing elementary stuff like this that breaks all builds try
> to apply some regexps on the Config files so that other builds don't
> break? Getting further is somewhat hard currently since the code almost
> instantly breaks after the last fixes are checked in..
>
> Stefan

config -> default

Greg Watson <[e-mail]> writes:
> Stefan,
>
> Which builds are broken? I thought I checked all configurations built after the
> change (apart from the VIA which Ron was working on.) and modified any that had
> problems.
>
> My hope was that this change would make the use of options more logical and
> consistent. The intention is that parts set default values for any options that
> they require or are specific to the part. Then when all the parts are put
> together in a target configuration file, these default values can be overridden
> for the specific build. I was also toying with the idea of allowing some options
>
> to be read-only, which I think would address your concern.
>
> Apologies for breaking things. I try to build all targets after any change like
> this to make sure things are still working.

Sorry for the great delay in checking this out.  But it actually is worse
than that.

The following totally fails with the new setup.  When USE_FALLBACK_IMAGE
is an option.

##
## Compute the location and size of where this firmware image
## (linuxBIOS plus bootloader) will live in the boot rom chip.
##
if USE_FALLBACK_IMAGE
	default ROM_SECTION_SIZE   = FALLBACK_SIZE
	default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE )
else
	default ROM_SECTION_SIZE   = ( ROM_SIZE - FALLBACK_SIZE )
	default ROM_SECTION_OFFSET = 0
end

Also this chunk where I over ride the default strings is necessary,
or I don't have matching motherboard vendor and part strings and I can't
flash my BIOS.

##
## Clean up the motherboard id strings
##
default MAINBOARD_PART_NUMBER="HDAMA"
default MAINBOARD_VENDOR="ARIMA"
 



Eric

config -> default

[ron minnich]

this fixup is at the top of next week's list now that sc '03 is over.

sc '03 is a major event that pretty much eats up nov. for us, so sorry for 
the inconvenience. 

ron

config -> default

ron minnich <[e-mail]> writes:
> this fixup is at the top of next week's list now that sc '03 is over.
>
> sc '03 is a major event that pretty much eats up nov. for us, so sorry for 
> the inconvenience.

Not a major problem.  Annoying to update config.g and not have your
BIOS flash for a multitude of reasons but not a major problem.  Mostly
I need the old expr or the equivalent to guarantee formulas and if
statements always use the final value of a variable.

The good news is that the default/option thing reverted I now am building
with the new build system and unless anyone else was using the old system
we can kill all of the Config files.

My focus right now is to get one last update for Lightning that is effectively
the current tree.  With better error handing for smbus failures and an optimized
number of resets so we have less exposure to smbus bugs.

While I am doing that I am finding that I am getting a lot of code review done
on things that I had to do quickly to get Lightning out the door and didn't quite
implement right.  

Once it looks like everything is in a reliable state for lightning
hopefully I can focus on what is needed to finish off the freebios2
core so we can freeze it at some point and start getting releases so
we can tell people where to look to build things.  I want to get the
pirq and mptables autogenerated.  And I think I want to do some
generalizations with respect to capabilities, so they can have methods
etc.  (Solving the problem of how to handle buggy HT devices).

Anyway I am rambling and I need to get home.  Talk to you after the Holidays.

Eric

config -> default

ron minnich <[e-mail]> writes:
> this fixup is at the top of next week's list now that sc '03 is over.
>
> sc '03 is a major event that pretty much eats up nov. for us, so sorry for 
> the inconvenience.

Any head way on this.   Especially the formulas which look
like they will need a second pass to get right?

And of course we still have some dependency problems with
the makefiles.

I'm not quite there but this is quickly becoming and itch I want
to scratch, unless someone is working on this.

Eric

config -> default

[Greg Watson]

I'm looking at it.

Greg

At 2:27 PM -0700 12/2/03, Eric W. Biederman wrote:
> ron minnich <[e-mail]> writes:
> > this fixup is at the top of next week's list now that sc '03 is over.
> >
> > sc '03 is a major event that pretty much eats up nov. for us, so sorry for
> >  the inconvenience.
>
> Any head way on this.   Especially the formulas which look
> like they will need a second pass to get right?
>
> And of course we still have some dependency problems with
> the makefiles.
>
> I'm not quite there but this is quickly becoming and itch I want
> to scratch, unless someone is working on this.
>
> Eric
> _______________________________________________
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

config -> default

[ron minnich]

On 2 Dec 2003, Eric W. Biederman wrote:
> Any head way on this.   Especially the formulas which look
> like they will need a second pass to get right?

it's moving.
> I'm not quite there but this is quickly becoming and itch I want
> to scratch, unless someone is working on this.

I would rather not see the old stuff re-appear that put perl eval commands 
into the makefile. I had linuxbios builds down to 10 seconds at one point, 
but it is creeping up again as people put stuff like this in:

export LINUXBIOS_BUILD:=$(shell date)
export LINUXBIOS_COMPILE_TIME:=$(shell date +%T)
export LINUXBIOS_COMPILE_BY:=$(shell whoami)
export LINUXBIOS_COMPILE_HOST:=$(shell hostname)
export LINUXBIOS_COMPILE_DOMAIN:=$(shell dnsdomainname)
export LINUXBIOS_COMPILER:=$(shell $(CC) $(CFLAGS) -v 2>&1 | tail -n 1)
export LINUXBIOS_LINKER:=$(shell  $(CC) -Wl,-v 2>&1 | grep version | tail 
-n 1)
export LINUXBIOS_ASSEMBLER:=$(shell  touch dummy.s ; $(CC) -c -Wa,-v 
dummy.s 2>&
1; rm -f dummy.s dummy.o )


I find the LINUXBIOS_ASSEMBLER one fairly distressing. Also, the
'dnsdomainname' has caused trouble in the past on machines which are not
using dns (these do exist).

ron