On 24 February 2014 17:10, Peter Maydell <peter.maydell@linaro.org> wrote:

On 24 February 2014 14:54, Rob Savoye <rob.savoye@linaro.org> wrote:
> On 02/24/2014 07:15 AM, Wookey wrote:
>> Where does a 'boards' file go/come from?
> It's a DejaGnu config file, used for remote testing.
>> Yes, or setting QEMU_UNAME on the command line, but I don't see how
>> those work well with the binfmt settings that simply give a binary to
>> run when the kernel spots the relevant binary magic. There is no
>> provision for options or env vars, and the whole thing is clearly going
>> to work much better if the binary just DTRT.
>
> I'm not using binfmt, DejaGnu fires up qemu-aarch64 with the
> executable name. What would I set QEMU_UNAME to ?

If you're using qemu master you shouldn't need to set it to
anything. It's an emergency-use mechanism in case a future
newer glibc wants an even newer kernel, but it shouldn't
be necessary right now, because qemu will automatically
force the reported kernel version to at least 3.8.0.

I'm not sure where the Ubuntu qemu patch came from (I didn't
think Ubuntu were shipping any aarch64 qemu just yet) but
it looks like part of the SuSE tree's workaround for this
issue, which we fixed in a cleaner way upstream.

Ubuntu passes --enable-uname-release=2.6.32 for configure, which overrides the clean way in upstream. Now, instead of doing the sane thing (dropping the configure argument) or submitting a useful patch, the problem was just wallpapered over by adding another override-of-override hidden in packaging...

That said, the overriding power of the configure flag against UNAME_MINIMUM_RELEASE is probably not very useful. We might want to drop the configure flag, and set an UNAME_MINIMUM_RELEASE for all targets. For people who still want to override, keep the enviroment variable setting available.