[prev in list] [next in list] [prev in thread] [next in thread]
List: linaro-toolchain
Subject: Re: [Weekly] 17-21 FEB 2013
From: Riku Voipio <riku.voipio () linaro ! org>
Date: 2014-02-24 17:27:30
Message-ID: CAAqcGHmzt9p0auvyP+bp12LV53OwtdQenhnr9x_zH7b_NE_t6A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 \
February 2014 17:10, Peter Maydell <span dir="ltr"><<a \
href="mailto:peter.maydell@linaro.org" \
target="_blank">peter.maydell@linaro.org</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
class="">On 24 February 2014 14:54, Rob Savoye <<a \
href="mailto:rob.savoye@linaro.org">rob.savoye@linaro.org</a>> wrote:<br>
> On 02/24/2014 07:15 AM, Wookey wrote:<br>
>> Where does a 'boards' file go/come from?<br>
> It's a DejaGnu config file, used for remote testing.<br>
>> Yes, or setting QEMU_UNAME on the command line, but I don't see how<br>
>> those work well with the binfmt settings that simply give a binary to<br>
>> run when the kernel spots the relevant binary magic. There is no<br>
>> provision for options or env vars, and the whole thing is clearly going<br>
>> to work much better if the binary just DTRT.<br>
><br>
> I'm not using binfmt, DejaGnu fires up qemu-aarch64 with the<br>
> executable name. What would I set QEMU_UNAME to ?<br>
<br>
</div>If you're using qemu master you shouldn't need to set it to<br>
anything. It's an emergency-use mechanism in case a future<br>
newer glibc wants an even newer kernel, but it shouldn't<br>
be necessary right now, because qemu will automatically<br>
force the reported kernel version to at least \
3.8.0.<br></blockquote><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm not sure where the Ubuntu qemu patch came from (I didn't<br>
think Ubuntu were shipping any aarch64 qemu just yet) but<br>
it looks like part of the SuSE tree's workaround for this<br>
issue, which we fixed in a cleaner way \
upstream.<br></blockquote><div><br></div><div><div>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...</div> </div><div><br></div><div>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. </div> <div><br></div></div></div></div>
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic