qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	Max Reitz <mreitz@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Cleber Rosa <crosa@redhat.com>
Subject: Re: [PATCH v4 1/3] qmp.py: change event_wait to use a dict
Date: Thu, 14 May 2020 17:59:52 +0200	[thread overview]
Message-ID: <20200514155952.GM5518@linux.fritz.box> (raw)
In-Reply-To: <de1026e4-9815-f89c-4cfd-6da35ac23197@redhat.com>

Am 14.05.2020 um 17:07 hat John Snow geschrieben:
> 
> 
> On 5/14/20 10:47 AM, Kevin Wolf wrote:
> > Am 14.05.2020 um 04:25 hat John Snow geschrieben:
> >> It's easier to work with than a list of tuples, because we can check the
> >> keys for membership.
> >>
> >> Signed-off-by: John Snow <jsnow@redhat.com>
> >> ---
> >>  python/qemu/machine.py        | 10 +++++-----
> >>  tests/qemu-iotests/040        | 12 ++++++------
> >>  tests/qemu-iotests/260        |  5 +++--
> >>  tests/qemu-iotests/iotests.py | 16 ++++++++--------
> >>  4 files changed, 22 insertions(+), 21 deletions(-)
> > 
> > I think you need to convert scripts/simplebench/bench_block_job.py, too.
> 
> Oh, right -- that one is new since I did this. A lot of these scripts
> need to be moved over into the python/ directory and managed under the
> same pylint/mypy regime as everything else.
> 
> A *ton* of our scripts are in various states of disrepair.

Is python/ actually supposed to have executable files in it? I thought
it was more for libraries.

> > 
> >> diff --git a/python/qemu/machine.py b/python/qemu/machine.py
> >> index b9a98e2c86..eaedc25172 100644
> >> --- a/python/qemu/machine.py
> >> +++ b/python/qemu/machine.py
> >> @@ -478,21 +478,21 @@ def event_wait(self, name, timeout=60.0, match=None):
> >>          timeout: QEMUMonitorProtocol.pull_event timeout parameter.
> >>          match: Optional match criteria. See event_match for details.
> >>          """
> >> -        return self.events_wait([(name, match)], timeout)
> >> +        return self.events_wait({name: match}, timeout)
> >>  
> >>      def events_wait(self, events, timeout=60.0):
> >>          """
> >>          events_wait waits for and returns a named event from QMP with a timeout.
> >>  
> >> -        events: a sequence of (name, match_criteria) tuples.
> >> +        events: a mapping containing {name: match_criteria}.
> >>                  The match criteria are optional and may be None.
> >>                  See event_match for details.  timeout:
> >>                  QEMUMonitorProtocol.pull_event timeout parameter.
> >>                  """
> >>          def _match(event):
> >> -            for name, match in events:
> >> -                if event['event'] == name and self.event_match(event, match):
> >> -                    return True
> >> +            name = event['event']
> >> +            if name in events:
> >> +                return self.event_match(event, events[name])
> > 
> > This part confused me a bit for a second. Of course, that's probably
> > mostly just me, but I feel 'events' isn't a good name any more when the
> > values of the dict are match strings rather than events.
> > 
> 
> This is honestly a really bad function. When I was trying to type
> everything, this one was at the bottom of the pile and it was the worst.
> 
> It needs an overhaul.
> 
> In my 32 patch series, I left the "match" types as "Any" pretty much
> everywhere, because it's such a laissez-faire series of functions.

It would require recursive types, which aren't supported yet. So I guess
Any is the best we can do at the moment.

> I'll keep the feedback in mind.
> 
> >>              return False
> >>  
> >>          # Search cached events
> >> diff --git a/tests/qemu-iotests/040 b/tests/qemu-iotests/040
> >> index 32c82b4ec6..90b59081ff 100755
> >> --- a/tests/qemu-iotests/040
> >> +++ b/tests/qemu-iotests/040
> >> @@ -485,12 +485,12 @@ class TestErrorHandling(iotests.QMPTestCase):
> >>  
> >>      def run_job(self, expected_events, error_pauses_job=False):
> >>          match_device = {'data': {'device': 'job0'}}
> >> -        events = [
> >> -            ('BLOCK_JOB_COMPLETED', match_device),
> >> -            ('BLOCK_JOB_CANCELLED', match_device),
> >> -            ('BLOCK_JOB_ERROR', match_device),
> >> -            ('BLOCK_JOB_READY', match_device),
> >> -        ]
> >> +        events = {
> >> +            'BLOCK_JOB_COMPLETED': match_device,
> >> +            'BLOCK_JOB_CANCELLED': match_device,
> >> +            'BLOCK_JOB_ERROR': match_device,
> >> +            'BLOCK_JOB_READY': match_device,
> >> +        }
> >>  
> >>          completed = False
> >>          log = []
> >> diff --git a/tests/qemu-iotests/260 b/tests/qemu-iotests/260
> >> index 804a7addb9..729f031122 100755
> >> --- a/tests/qemu-iotests/260
> >> +++ b/tests/qemu-iotests/260
> >> @@ -67,8 +67,9 @@ def test(persistent, restart):
> >>  
> >>      vm.qmp_log('block-commit', device='drive0', top=top,
> >>                 filters=[iotests.filter_qmp_testfiles])
> >> -    ev = vm.events_wait((('BLOCK_JOB_READY', None),
> >> -                         ('BLOCK_JOB_COMPLETED', None)))
> >> +    ev = vm.events_wait({
> >> +        'BLOCK_JOB_READY': None,
> >> +        'BLOCK_JOB_COMPLETED': None })
> > 
> > So, I'm not sure if this is nitpicking or rather bikeshedding, but
> > having the closing brackets on the next line would be more consistent
> > with the other instances in this patch.
> > 
> 
> Nah, it's fine. I'll clean it up. This is pretty close to an RFC series
> anyway, so I didn't really polish it.
> 
> (Or, I will try to clean it up. I probably won't work on it again in the
> near term. I think I just wanted to see if this seemed useful in general
> to people.

Ah, there isn't much missing for this series, though. We don't have to
wait for a fix-the-world series when we can incrementally improve
things.

> As part of maybe moving the python library onto a package, I thought
> that maybe developing a JobRunner tool would be useful to have in that
> library. As you can see, I nestled it into iotests.py, though.)

Let's just do that now, we can always move it somewhere else later.

Kevin



  reply	other threads:[~2020-05-14 16:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  2:25 [PATCH v4 0/3] iotests: add JobRunner framework John Snow
2020-05-14  2:25 ` [PATCH v4 1/3] qmp.py: change event_wait to use a dict John Snow
2020-05-14 14:47   ` Kevin Wolf
2020-05-14 15:07     ` John Snow
2020-05-14 15:59       ` Kevin Wolf [this message]
2020-05-14 19:31         ` John Snow
2020-06-16 21:41           ` Eric Blake
2020-06-17  2:49             ` John Snow
2020-05-14  2:25 ` [PATCH v4 2/3] iotests: add JobRunner class John Snow
2020-05-14 15:40   ` Kevin Wolf
2020-05-14 19:32     ` John Snow
2020-05-14  2:25 ` [PATCH v4 3/3] iotests: modify test 040 to use JobRunner John Snow
2020-05-14 15:53   ` Kevin Wolf
2020-05-14 19:37     ` John Snow
2020-05-15  9:46       ` Kevin Wolf

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=20200514155952.GM5518@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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 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).