autotest: Make the "ltp" test comile on ARM.

autotest: Make the "ltp" test comile on ARM.

- Add a utility function to wrap "./configure" to pass appropriate "--host",
  "--target", and "--build" options to configure.
- Change the ltp test to use said utility
- Workaround an internal compiler error in "ltp".  The epoll-ltp.c test
  writes zero to an uint64_t through an unaligned pointer.  This causes our
  compiler to die.  The behavior is undefined by the C standard (C99 Section
  6.3.2.3) and I suspect that even if it did compile it would cause a "bus
  error" on ARM.  I replaced the assignment with a call to memset.

TEST=Built for x86-generic and arm-generic
BUG=None

[ericli, 2010-03-23 01:20:52]

Ken,

Thanks to fix this for us. Really great.

But please help to make this upstream compatible, since ltp belongs to upstream.

There is good samples:
http://autotest.kernel.org/browser/trunk/client/tests/dbench/dbench.py

Martin could help to push the upstream changes. You just send him the PATCH. :)


On 2010/03/23 01:12:45, Kenneth Waters wrote:
>

[Kenneth Waters, 2010-03-23 01:26:24]

> But please help to make this upstream compatible, since ltp belongs to
upstream.

While I would normally agree with you, this change is very gentoo/ChromeOS
specific.  So is the DBench one you link.  Does it really belong in autotest
proper?  There was talk about forking ltp into site_tests, and making the change
there; we decided against it because there where already local changes to ltp in
the ChromeOS tree.

[mbligh_google.com, 2010-03-23 01:44:03]

On Tue, Mar 23, 2010 at 1:26 AM,  <kwaters@chromium.org> wrote:
>> But please help to make this upstream compatible, since ltp belongs to
>
> upstream.
>
> While I would normally agree with you, this change is very gentoo/ChromeOS
> specific.

Confused - one part looks like a general ARM fix for LTP to me?
The rest we could pick up from the enviroment etc if need be?

> So is the DBench one you link.  Does it really belong in autotest
> proper?  There was talk about forking ltp into site_tests, and making the
> change
> there; we decided against it because there where already local changes to
> ltp in
> the ChromeOS tree.
>
> http://codereview.chromium.org/1161005
>

[Kenneth Waters, 2010-03-23 02:08:21]

> > While I would normally agree with you, this change is very gentoo/ChromeOS
> > specific.
> 
> Confused - one part looks like a general ARM fix for LTP to me?
> The rest we could pick up from the enviroment etc if need be?

The change to LTP should be pushed.

CHOST, CTARGET, CBUILD are Gentoo specific, I don't know why autotest would want
to take those changes.

[mbligh_google.com, 2010-03-23 02:14:56]

On Tue, Mar 23, 2010 at 2:08 AM,  <kwaters@chromium.org> wrote:
>> > While I would normally agree with you, this change is very
>> > gentoo/ChromeOS
>> > specific.
>
>> Confused - one part looks like a general ARM fix for LTP to me?
>> The rest we could pick up from the enviroment etc if need be?
>
> The change to LTP should be pushed.
>
> CHOST, CTARGET, CBUILD are Gentoo specific, I don't know why autotest would
> want
> to take those changes.

autotest spans all distros, so Gentoo is no problem.

+    if 'CBUILD' in os.environ:
+        args.append('--build=' + os.environ['CBUILD'])

seems like it's generic enough to do no harm to other distros,
as presumably they won't have it set?

[Kenneth Waters, 2010-03-23 02:39:37]

I thought about this a little more, you guys are right.  I'll remove the utility
function, and move the stuff into the test file.  The autotest maintainers can
merge the change if it suits them.

I'll also send the ltp patch to the ltp mailing list.

[Kenneth Waters, 2010-03-23 16:50:00]

Martin, Eric,

Tedbo liked the idea of the configure wrapper; do you mind if I move it into
"common_lib.utils" and change the tests to use it?

[petkov, 2010-03-23 16:53:56]

It's good to have a configure wrapper -- it would be useful for other tests
(e.g., SAT). What was the issue with site_build? I think there was some
resistance from autotest upstream to stuffing too much random methods in
utils...

On Tue, Mar 23, 2010 at 9:50 AM, <kwaters@chromium.org> wrote:

> Martin, Eric,
>
> Tedbo liked the idea of the configure wrapper; do you mind if I move it
> into
> "common_lib.utils" and change the tests to use it?
>
>
> http://codereview.chromium.org/1161005
>

[mbligh_google.com, 2010-03-23 18:31:17]

I think we have client/bin/chrome_utils.py or similar now.

On Tue, Mar 23, 2010 at 9:57 AM, Eric Li(李咏竹) <ericli@google.com> wrote:
> I like this as a design. But as Martin mentioned out, this should not be
> site specific. why not simply add a simple configure method under
> client/bin/test.py
>
>
> On Tue, Mar 23, 2010 at 9:50 AM, <kwaters@chromium.org> wrote:
>>
>> Martin, Eric,
>>
>> Tedbo liked the idea of the configure wrapper; do you mind if I move it
>> into
>> "common_lib.utils" and change the tests to use it?
>>
>> http://codereview.chromium.org/1161005
>
>
>
> --
> Eric Li
> 李咏竹
> Google Kirkland
>
>
>

[Kenneth Waters, 2010-03-23 18:32:16]

ptal.

If you don't like the location of "configure()" please suggest another one.

[mbligh, 2010-03-23 18:38:16]

LGTM

[ericli, 2010-03-23 18:40:15]

http://codereview.chromium.org/1161005/diff/11001/5002
File client/common_lib/utils.py (right):

http://codereview.chromium.org/1161005/diff/11001/5002#newcode1252
client/common_lib/utils.py:1252: def configure(extra=None,
configure='./configure'):
Move this function to client/common_lib/test.py

[Kenneth Waters, 2010-03-23 21:43:26]

http://codereview.chromium.org/1161005/diff/11001/5002
File client/common_lib/utils.py (right):

http://codereview.chromium.org/1161005/diff/11001/5002#newcode1252
client/common_lib/utils.py:1252: def configure(extra=None,
configure='./configure'):
On 2010/03/23 18:40:16, ericli wrote:
> Move this function to client/common_lib/test.py

Which part; inside the base_test class or into the module?  It really doesn't
feel like it belongs inside the base_test class, it doesn't use any members. 
And if it's in the module it's a giant pain to use, because common_lib.test
namespace collides with client.bin.test.  Can you explain your thinking?

[mbligh_google.com, 2010-03-23 22:01:43]

On Tue, Mar 23, 2010 at 2:43 PM,  <kwaters@chromium.org> wrote:
>
> http://codereview.chromium.org/1161005/diff/11001/5002
> File client/common_lib/utils.py (right):
>
> http://codereview.chromium.org/1161005/diff/11001/5002#newcode1252
> client/common_lib/utils.py:1252: def configure(extra=None,
> configure='./configure'):
> On 2010/03/23 18:40:16, ericli wrote:
>>
>> Move this function to client/common_lib/test.py
>
> Which part; inside the base_test class or into the module?  It really
> doesn't feel like it belongs inside the base_test class, it doesn't use
> any members.  And if it's in the module it's a giant pain to use,
> because common_lib.test namespace collides with client.bin.test.  Can
> you explain your thinking?

It seems to me that we'll only run this as part of the client code
(even though we're physically executing this on the server)
so I'd think client/common_lib wasn't necessary?

[ericli, 2010-03-23 22:58:51]

inside client/common_lib/test.py and base_test class.  This is where setup()
is initially defined and since configure() is called inside setup()....


On Tue, Mar 23, 2010 at 3:01 PM, Martin Bligh <mbligh@google.com> wrote:

> On Tue, Mar 23, 2010 at 2:43 PM,  <kwaters@chromium.org> wrote:
> >
> > http://codereview.chromium.org/1161005/diff/11001/5002
> > File client/common_lib/utils.py (right):
> >
> > http://codereview.chromium.org/1161005/diff/11001/5002#newcode1252
> > client/common_lib/utils.py:1252: def configure(extra=None,
> > configure='./configure'):
> > On 2010/03/23 18:40:16, ericli wrote:
> >>
> >> Move this function to client/common_lib/test.py
> >
> > Which part; inside the base_test class or into the module?  It really
> > doesn't feel like it belongs inside the base_test class, it doesn't use
> > any members.  And if it's in the module it's a giant pain to use,
> > because common_lib.test namespace collides with client.bin.test.  Can
> > you explain your thinking?
>
> It seems to me that we'll only run this as part of the client code
> (even though we're physically executing this on the server)
> so I'd think client/common_lib wasn't necessary?
>



-- 
Eric Li
李咏竹
Google Kirkland

[Kenneth Waters, 2010-03-23 23:00:28]

On 2010/03/23 22:58:51, ericli wrote:
> inside client/common_lib/test.py and base_test class.  This is where setup()
> is initially defined and since configure() is called inside setup()....

OK. ptal.

[Kenneth Waters, 2010-03-24 00:03:28]

ptal.  I moved back to utils, based on experience with sysstat.

[ericli, 2010-03-24 00:10:00]

LGTM.
Thanks.

On 2010/03/24 00:03:28, Kenneth Waters wrote:
> ptal.  I moved back to utils, based on experience with sysstat.

[mbligh, 2010-03-24 00:11:18]

On 2010/03/24 00:03:28, Kenneth Waters wrote:
> ptal.  I moved back to utils, based on experience with sysstat.

LGTM. 

I'm not fussed either way ;-)