Jordan,
What benefit do we get from patching Config.lb instead of just copying a new one into the directory? It seems like the same thing, only the complete Config.lb would be more human readable.
I just thought that as long as you are regenerating those patches, we might want to reconsider how we do it.
One of the implications is that now if you switch payloads in buildrom, Coreboot needs to be unpacked again, because the patch won't apply. If we used a new Config.lb, we could just copy over it and run buildtarget again.
Myles
On 25/01/08 10:39 -0700, Myles Watson wrote:
Jordan,
What benefit do we get from patching Config.lb instead of just copying a new one into the directory? It seems like the same thing, only the complete Config.lb would be more human readable.
I just thought that as long as you are regenerating those patches, we might want to reconsider how we do it.
One of the implications is that now if you switch payloads in buildrom, Coreboot needs to be unpacked again, because the patch won't apply. If we used a new Config.lb, we could just copy over it and run buildtarget again.
I agree with all of this. We should switch to complete Config.lbs for v2.
Also, the reason why I haven't submitted my patch is that buildtarget is still broken for -fno-stack-protector (as per a previous email), and I figured that as long as I was moving all the revisions up, I would wait for that to work, but I can't wait much longer, and I really don't grok how the config system works enough to hack on it without getting lost.
Jordan
On Fri, Jan 25, 2008 at 10:44:38AM -0700, Jordan Crouse wrote:
I agree with all of this. We should switch to complete Config.lbs for v2.
Also, the reason why I haven't submitted my patch is that buildtarget is still broken for -fno-stack-protector (as per a previous email), and I figured that as long as I was moving all the revisions up, I would wait for that to work, but I can't wait much longer, and I really don't grok how the config system works enough to hack on it without getting lost.
buildtarget uses a thirdparty config parsing thingy in python to first load the set of available options (from Options.lb) and then read their values. (Config.lb)
We were discussing an overlay config - that is applied after the current Config.lb if specified in an environment variable. Is that still interesting? Would it solve the problem? I think that's a quick hack, I could take a look.
//Peter
On Jan 25, 2008 10:07 AM, Peter Stuge peter@stuge.se wrote:
We were discussing an overlay config - that is applied after the current Config.lb if specified in an environment variable. Is that still interesting? Would it solve the problem? I think that's a quick hack, I could take a look.
Let's just fix the buildtarget problem and put the config tool to rest.
I think the buildtarget remaining fix is simple, I just can't do it right now.
the overlay Config.lb would not fix the problem with -f no-stack-protector.
ron
-
Jordan Crouse -
Myles Watson -
Peter Stuge -
ron minnich