From: "Andreas Färber" <afaerber@suse.de>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: pbonzini@redhat.com, Cam Macdonell <cam@cs.ualberta.ca>,
qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] [RFC] tests: Add ivshmem qtest
Date: Thu, 03 Apr 2014 13:45:28 +0200 [thread overview]
Message-ID: <533D49D8.3010601@suse.de> (raw)
In-Reply-To: <20140403084624.GD27704@stefanha-thinkpad.redhat.com>
Am 03.04.2014 10:46, schrieb Stefan Hajnoczi:
> On Wed, Apr 02, 2014 at 04:57:48PM +0200, Andreas Färber wrote:
>> +int main(int argc, char **argv)
>> +{
>> + QTestState *s1, *s2;
>> + char *cmd;
>> + int ret;
>> +
>> + g_test_init(&argc, &argv, NULL);
>> + qtest_add_func("/ivshmem/nop", nop);
>> +
>> + cmd = g_strdup_printf("-device ivshmem,shm=%s,size=1M", "qtest");
>
> This test leaks the "qtest" shm object that gets created by the first
> QEMU process. The name is constant so two instances of the test cannot
> run in parallel on the same machine (the objects go in /dev/shm).
Right. Therefore it's already using %s and not a fully hardcoded string.
> The name should be unique and we should clean up in both success and
> failure (abort(3)) cases.
The recipe for unique filenames elsewhere is mkstemp(), which I was
planning to use here as well using "/dev/shm/qtest.XXXXXX" and then to
somehow strip the /dev/shm/ part, e.g. &...[9].
However I do not see any existing test specially cleaning up such
temporary files on SIGABRT rather than just on success. Do you have a
pointer or suggestion how to do that?
Still the actual question of this RFC is, how do I detect whether we may
run this test at all?
1) Relying on being run in the build directory, we could try to peek at
$arch-softmmu/config-target.mak, looking for CONFIG_KVM. Ugly.
2) Determine via QMP whether KVM is available in the QEMU binary. How?
Involves an additional process before launching the actual process with
-device ivshmem.
3) Determine via QMP whether the device QOM type is available in the
QEMU binary. Involves an additional process.
4) Make ivshmem build independent of CONFIG_KVM. Too much work for a
single out of many test cases.
5) ???
Thanks,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2014-04-03 11:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 14:57 [Qemu-devel] [RFC] tests: Add ivshmem qtest Andreas Färber
2014-04-02 15:06 ` Michael S. Tsirkin
2014-04-02 15:07 ` Andreas Färber
2014-04-02 15:15 ` Michael S. Tsirkin
2014-04-02 15:15 ` Paolo Bonzini
2014-04-03 11:16 ` Michael S. Tsirkin
2014-04-03 11:23 ` Andreas Färber
2014-04-03 13:33 ` Michael S. Tsirkin
2014-04-03 8:46 ` Stefan Hajnoczi
2014-04-03 11:45 ` Andreas Färber [this message]
2014-04-03 12:58 ` Stefan Hajnoczi
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=533D49D8.3010601@suse.de \
--to=afaerber@suse.de \
--cc=cam@cs.ualberta.ca \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@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.