qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Straub <lukasstraub2@web.de>
To: Thomas Huth <thuth@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	Marc-Andre Lureau <marcandre.lureau@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Li Zhang <zhlcindy@gmail.com>
Subject: Re: [PATCH 1/5] tests: Use the normal yank code instead of stubs in relevant tests
Date: Tue, 23 Mar 2021 15:54:22 +0100	[thread overview]
Message-ID: <20210323154935.521714df@gecko.fritz.box> (raw)
In-Reply-To: <5c37e536-14bb-37fc-8dfb-2d776f763c63@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4094 bytes --]

On Tue, 23 Mar 2021 05:46:24 +0100
Thomas Huth <thuth@redhat.com> wrote:

> On 22/03/2021 18.48, Lukas Straub wrote:
> > On Mon, 22 Mar 2021 17:00:23 +0100
> > Thomas Huth <thuth@redhat.com> wrote:
> >   
> >> On 22/03/2021 08.35, Lukas Straub wrote:  
> >>> On Mon, 22 Mar 2021 06:20:50 +0100
> >>> Thomas Huth <thuth@redhat.com> wrote:
> >>>      
> >>>> On 22/03/2021 00.31, Lukas Straub wrote:  
> >>>>> Use the normal yank code instead of stubs in relevant tests to
> >>>>> increase coverage and to ensure that registering and unregistering
> >>>>> of yank instances and functions is done correctly.
> >>>>>
> >>>>> Signed-off-by: Lukas Straub <lukasstraub2@web.de>
> >>>>> ---
> >>>>>     tests/qtest/meson.build | 6 +++---
> >>>>>     tests/unit/meson.build  | 4 ++--
> >>>>>     2 files changed, 5 insertions(+), 5 deletions(-)
> >>>>>
> >>>>> diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
> >>>>> index 66ee9fbf45..40e1f495f7 100644
> >>>>> --- a/tests/qtest/meson.build
> >>>>> +++ b/tests/qtest/meson.build
> >>>>> @@ -234,9 +234,9 @@ tpmemu_files = ['tpm-emu.c', 'tpm-util.c', 'tpm-tests.c']
> >>>>>     qtests = {
> >>>>>       'bios-tables-test': [io, 'boot-sector.c', 'acpi-utils.c', 'tpm-emu.c'],
> >>>>>       'cdrom-test': files('boot-sector.c'),
> >>>>> -  'dbus-vmstate-test': files('migration-helpers.c') + dbus_vmstate1,
> >>>>> +  'dbus-vmstate-test': ['migration-helpers.c', dbus_vmstate1, '../../monitor/yank.c'],
> >>>>>       'ivshmem-test': [rt, '../../contrib/ivshmem-server/ivshmem-server.c'],
> >>>>> -  'migration-test': files('migration-helpers.c'),
> >>>>> +  'migration-test': ['migration-helpers.c', io, '../../monitor/yank.c'],
> >>>>>       'pxe-test': files('boot-sector.c'),
> >>>>>       'qos-test': [chardev, io, qos_test_ss.apply(config_host, strict: false).sources()],
> >>>>>       'tpm-crb-swtpm-test': [io, tpmemu_files],  
> >>>>
> >>>> Is this really necessary for the qtests? I can understand the change for the
> >>>> unit tests, but the qtests are separate programs where I could not imagine
> >>>> that they use the yank functions in any way?  
> >>>
> >>> Yes, it is necessary. While the yank functions are not called in these tests,
> >>> it still checks that registering and unregistering of yank instances and
> >>> functions is done correctly. I.e. That no yank functions are registered before
> >>> the instance, that the yank instance is only unregistered after all functions
> >>> where unregistered, that the same instance is not registered twice and that
> >>> the yank instance actually exists before it is unregistered.  
> >>
> >> Now you even confused me more. Could you elaborate a little bit? If none of
> >> the functions are called by the test, which part of yank.c is excercised
> >> here at all? Could you give a more detailed example? The only thing I could
> >> imagine is yank_init(), but that does not look like something we need to
> >> check in a qtest ?  
> > 
> > Oh, sorry. I meant yank's concept of a yank function here. It works this way:
> > The different subsystems first register a yank instance. So in this case
> > when starting migration in the test, the migration code first registers a
> > yank instance. Then, it registers _yank functions_ with this instance, for
> > for example to shutdown a socket.  
> 
> But these are the qtest, separate stand-alone programs. The migration code 
> of QEMU (i.e. the code in the main "migration" folder) is not linked into 
> these binaries. Doing something like:
> 
>   grep -r yank tests/qtest/migration-test
> 
> should give you zero results. Thus it IMHO does not make sense to add the 
> yank.c to these tests here.
> 
> Having said that, it seems like the qos-test is linking against the chardev 
> code and thus might use indirectly the yank code there. So you maybe might 
> want to add it to the qos-test instead?

Ok, now I understand. In that case it doesn't matter if full yank is linked
into qtest.

Regards,
Lukas Straub

>   Thomas
> 



-- 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-03-23 14:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-21 23:31 [PATCH 0/5] yank: Add chardev tests and fixes Lukas Straub
2021-03-21 23:31 ` [PATCH 1/5] tests: Use the normal yank code instead of stubs in relevant tests Lukas Straub
2021-03-22  5:20   ` Thomas Huth
2021-03-22  7:35     ` Lukas Straub
2021-03-22 16:00       ` Thomas Huth
2021-03-22 17:48         ` Lukas Straub
2021-03-23  4:46           ` Thomas Huth
2021-03-23 14:54             ` Lukas Straub [this message]
2021-03-21 23:31 ` [PATCH 2/5] tests: Add tests for yank with the chardev-change Lukas Straub
2021-03-22  8:04   ` Marc-André Lureau
2021-03-21 23:31 ` [PATCH 3/5] chardev/char.c: Move object_property_try_add_child out of chardev_new Lukas Straub
2021-03-22  8:42   ` Marc-André Lureau
2021-03-21 23:31 ` [PATCH 4/5] chardev/char.c: Always pass id to chardev_new Lukas Straub
2021-03-22  8:33   ` Marc-André Lureau
2021-03-22 10:32   ` Li Zhang
2021-03-21 23:32 ` [PATCH 5/5] chardev: Fix yank with the chardev-change case Lukas Straub
2021-03-22  8:32   ` Marc-André Lureau

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=20210323154935.521714df@gecko.fritz.box \
    --to=lukasstraub2@web.de \
    --cc=armbru@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=zhlcindy@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).