On Tue, Jul 21, 2020 at 11:03:58PM +0200, Gerd Hoffmann wrote:
I'm fine with tagging a new release. I'm not sure we'll necessarily match QEMU's schedule though. How about we target July 24th for the release?
That'll be fine. Early enough for -rc2, if something goes wrong we have -rc3 as fallback.
I'll go update seabios to a snapshot beforehand, so seabios will get more testing and also to keep the delta small when updating to the released version during the freeze.
What's your thoughts on this release and the recent ld issue? We can change SeaBIOS to work around the upstream change to ld and push it into this release (likely with a delay) or we can go forward with the release as is.
What kind of workaround? The binary patching with dd? I don't like it much, but given that the linux kernel does the same already the risk that it'll break something should be low, so I think we can do it.
Yes, the binary patching approach, but I'd use a python script instead of printf/dd - I sent a patch to the list.
Longer-term it probably makes sense to look at the .incbin idea for a less hacky way to solve the problem. But that surely isn't something we want do only days before a release ...
Unfortunately, I'm not sure .incbin will make sense. As I understand it, using .incbin would require writing a script to find all sections in the given object file, run objdump on each section, auto-generate an asssembler file with .incbin for every section, and then compile that assembler file. The end result would be a .o file that matches the original .o file, but with the single flag cleared.
It might make sense to update layoutrom.py to just manually generate the final binary. (That is, to avoid using ld at all.) That is a bunch of work though.
In any case, I agree, it doesn't make sense to take that on just prior to a release.
-Kevin