All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cole Robinson <crobinso@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH kvm-unit-tests v2 0/4] Have x86-run parse unittests.cfg
Date: Mon, 15 Apr 2013 09:40:52 -0400	[thread overview]
Message-ID: <516C0364.8090308@redhat.com> (raw)
In-Reply-To: <516BDACE.9030005@redhat.com>

On 04/15/2013 06:47 AM, Paolo Bonzini wrote:
> Il 15/04/2013 10:30, Kevin Wolf ha scritto:
>> Am 14.04.2013 um 20:18 hat Cole Robinson geschrieben:
>>>> First two patches are trivial bits. Rest rewrites x86-run in python,
>>>> which then makes it easy to parse unittests.cfg. This makes it
>>>> simpler to invoke individual unittests the same way autotest does.
>>>>
>>>> Kevin has a similar series[1], but I'm reposting this for completeness.
>>>>
>>>> [1] http://www.spinics.net/lists/kvm/msg89471.html
>> As long as it doesn't take away functionality, it wouldn't even conflict
>> with my series. Unfortunately, it seems it does: The old x86-run
>> forwarded any additional options to the qemu binary, now there isn't any
>> way to specify options on the command line, but it always does its magic.
>>
>> The other problem I mentioned in the other thread is that you assume
>> that the kernel file name and the configuration section are the same.
>> The test cases that exist in the configuration file with several
>> different argument strings are a strong hint that this assumption is
>> invalid.
>>
>> Maybe it's really best to keep x86-run the thin wrapper that is today
>> and add a second script like my series does for a higher level tool.
>> (Though I must admit that this wasn't by design, my script was written
>> before x86-run existed and used to be standalone. I just called into
>> x86-run with this rebase to avoid duplicating things. But now it
>> actually seems to be the right choice, even if accidental.)
> 
> I also prefer Kevin's series, though rewriting run_tests.sh in Python
> would probably make it nicer.
> 

Yeah the only missing 'feature' that my series has over Kevin's is re-writing
the script in python :)

I'm happy with Kevin's series as well.

- Cole


      reply	other threads:[~2013-04-15 13:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-14 18:18 [PATCH kvm-unit-tests v2 0/4] Have x86-run parse unittests.cfg Cole Robinson
2013-04-14 18:18 ` [PATCH kvm-unit-tests v2 1/4] .gitignore: Add *.flat and config.mak Cole Robinson
2013-04-14 18:18 ` [PATCH kvm-unit-tests v2 2/4] x86/run-kvm-unit-tests: Drop it Cole Robinson
2013-04-14 18:18 ` [PATCH kvm-unit-tests v2 3/4] Rewrite x86-run in python Cole Robinson
2013-04-14 18:18 ` [PATCH kvm-unit-tests v2 4/4] x86-run: Pull extra arguments from unittests.cfg Cole Robinson
2013-04-15  8:30 ` [PATCH kvm-unit-tests v2 0/4] Have x86-run parse unittests.cfg Kevin Wolf
2013-04-15 10:47   ` Paolo Bonzini
2013-04-15 13:40     ` Cole Robinson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=516C0364.8090308@redhat.com \
    --to=crobinso@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.