From: Laszlo Ersek <lersek@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 2/4] i440fx-test: give each GTest case its own qtest
Date: Fri, 29 Nov 2013 16:35:52 +0100 [thread overview]
Message-ID: <5298B458.4050203@redhat.com> (raw)
In-Reply-To: <20131129145346.GA8313@otherpad.lan.raisama.net>
On 11/29/13 15:53, Eduardo Habkost wrote:
> On Thu, Nov 28, 2013 at 07:09:13PM +0100, Laszlo Ersek wrote:
>> The current two GTest cases, /i440fx/defaults and /i440fx/pam can share a
>> qemu process, but the next two cases will need dedicated instances. It is
>> messy (and order-dependent) to dynamically configure GTest cases one by
>> one to start, stop, or keep the current qtest (*); let's just have each
>> GTest work with its own qtest. The performance difference should be
>> negligible.
>>
>> (*) As g_test_run() can be invoked at most once per process startup, and
>> it runs GTest cases in sequence, we'd need clumsy data structures to
>> control each GTest case to start/stop/keep the qemu instance. Or, we'd
>> have to code the same information into the test methods themselves, which
>> would make them even more order-dependent.
>>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> [...]
>> static void test_i440fx_defaults(gconstpointer opaque)
>> {
>> const TestData *s = opaque;
>> + QPCIBus *bus;
>> QPCIDevice *dev;
>> uint32_t value;
>>
>> - dev = qpci_device_find(s->bus, QPCI_DEVFN(0, 0));
>> + bus = test_start_get_bus(s);
>> + dev = qpci_device_find(bus, QPCI_DEVFN(0, 0));
>
> You can use GTest setup/teardown functions to do this automatically on
> all tests, but I am not sure the code really looks better when using it.
> I gave it a try and it looks like this:
>
> diff --git a/tests/i440fx-test.c b/tests/i440fx-test.c
> index 6ac46bf..c9d6f6a 100644
> --- a/tests/i440fx-test.c
> +++ b/tests/i440fx-test.c
> @@ -25,15 +25,35 @@
>
> #define ARRAY_SIZE(array) (sizeof(array) / sizeof((array)[0]))
>
> -typedef struct TestData
> +typedef struct TestArgs
> {
> int num_cpus;
> +} TestArgs;
> +
> +typedef struct TestData
> +{
> QPCIBus *bus;
> } TestData;
>
> -static void test_i440fx_defaults(gconstpointer opaque)
> +static void test_setup(TestData *s, gconstpointer user_data)
> +{
> + const TestArgs *args = user_data;
> + char *cmdline;
> +
> + cmdline = g_strdup_printf("-smp %d", args->num_cpus);
> + qtest_start(cmdline);
> + g_free(cmdline);
> + s->bus = qpci_init_pc();
> +}
> +
> +static void test_teardown(TestData *s, gconstpointer user_data)
> +{
> + qtest_end();
> +}
> +
> +static void test_i440fx_defaults(TestData *s, gconstpointer user_data)
> {
> - const TestData *s = opaque;
> + const TestArgs *args = user_data;
> QPCIDevice *dev;
> uint32_t value;
>
> @@ -62,7 +82,7 @@ static void test_i440fx_defaults(gconstpointer opaque)
>
> /* 3.2.11 */
> value = qpci_config_readw(dev, 0x50); /* PMCCFG */
> - if (s->num_cpus == 1) { /* WPE */
> + if (args->num_cpus == 1) { /* WPE */
> g_assert(!(value & (1 << 15)));
> } else {
> g_assert((value & (1 << 15)));
> @@ -176,9 +196,8 @@ static void write_area(uint32_t start, uint32_t end, uint8_t value)
> g_free(data);
> }
>
> -static void test_i440fx_pam(gconstpointer opaque)
> +static void test_i440fx_pam(TestData *s, gconstpointer user_data)
> {
> - const TestData *s = opaque;
> QPCIDevice *dev;
> int i;
> static struct {
> @@ -258,26 +277,16 @@ static void test_i440fx_pam(gconstpointer opaque)
>
> int main(int argc, char **argv)
> {
> - TestData data;
> - char *cmdline;
> int ret;
> + TestArgs args = { .num_cpus = 1 };
>
> g_test_init(&argc, &argv, NULL);
>
> - data.num_cpus = 1;
> -
> - cmdline = g_strdup_printf("-smp %d", data.num_cpus);
> - qtest_start(cmdline);
> - g_free(cmdline);
> -
> - data.bus = qpci_init_pc();
> -
> - g_test_add_data_func("/i440fx/defaults", &data, test_i440fx_defaults);
> - g_test_add_data_func("/i440fx/pam", &data, test_i440fx_pam);
> + g_test_add("/i440fx/defaults", TestData, &args, test_setup,
> + test_i440fx_defaults, test_teardown);
> + g_test_add("/i440fx/pam", TestData, &args, test_setup,
> + test_i440fx_pam, test_teardown);
>
> ret = g_test_run();
> -
> - qtest_end();
> -
> return ret;
> }
>
I agree that this specific use of the fixtures doesn't really pay off.
Thank you
Laszlo
next prev parent reply other threads:[~2013-11-29 15:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-28 18:09 [Qemu-devel] [PATCH v2 0/4] i440fx-test: check firmware visibility Laszlo Ersek
2013-11-28 18:09 ` [Qemu-devel] [PATCH v2 1/4] i440fx-test: qtest_start() should be paired with qtest_end() Laszlo Ersek
2013-11-29 13:23 ` Markus Armbruster
2013-11-28 18:09 ` [Qemu-devel] [PATCH v2 2/4] i440fx-test: give each GTest case its own qtest Laszlo Ersek
2013-11-29 14:53 ` Eduardo Habkost
2013-11-29 15:35 ` Laszlo Ersek [this message]
2013-11-28 18:09 ` [Qemu-devel] [PATCH v2 3/4] i440fx-test: generate temporary firmware blob Laszlo Ersek
2013-11-29 13:57 ` Markus Armbruster
2013-11-29 15:07 ` Laszlo Ersek
2013-11-29 16:26 ` Paolo Bonzini
2013-12-02 9:28 ` Markus Armbruster
2013-11-28 18:09 ` [Qemu-devel] [PATCH v2 4/4] i440fx-test: verify firmware under 4G and 1M, both -bios and -pflash Laszlo Ersek
2013-11-29 14:09 ` Markus Armbruster
2013-11-29 15:30 ` Laszlo Ersek
2013-11-29 16:29 ` Paolo Bonzini
2013-11-28 18:18 ` [Qemu-devel] [PATCH v2 0/4] i440fx-test: check firmware visibility Laszlo Ersek
2013-11-29 17:12 ` Andreas Färber
2013-11-29 17:18 ` Laszlo Ersek
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=5298B458.4050203@redhat.com \
--to=lersek@redhat.com \
--cc=ehabkost@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.