All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "fam@euphon.net" <fam@euphon.net>,
	"stefanha@redhat.com" <stefanha@redhat.com>,
	"jcody@redhat.com" <jcody@redhat.com>,
	"kwolf@redhat.com" <kwolf@redhat.com>,
	Denis Lunev <den@virtuozzo.com>,
	"eblake@redhat.com" <eblake@redhat.com>,
	"jsnow@redhat.com" <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 05/11] iotests: allow resume_drive by node name
Date: Wed, 16 Jan 2019 14:11:25 +0100	[thread overview]
Message-ID: <fab4d292-ea59-5e1f-ec43-486abc455e7c@redhat.com> (raw)
In-Reply-To: <084ff0b6-1de8-1c17-f085-97a8b1aeb8b5@virtuozzo.com>

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

On 14.01.19 17:06, Vladimir Sementsov-Ogievskiy wrote:
> 14.01.2019 17:46, Max Reitz wrote:
>> On 29.12.18 13:20, Vladimir Sementsov-Ogievskiy wrote:
>>> After node graph changes, we may not be able to resume_drive by device
>>> name (backing files are not recursively searched). So, lets allow to
>>> resume by node-name. Set constant name for breakpoints, to avoid
>>> introducing extra parameters.
>>
>> Hm, I don't quite understand this reason.  Is this so you can create
>> breakpoints on one node (which falls through to the first blkdebug node)
>> and then remove them from another (falling through to the same blkdebug
>> node)?
> 
> add/remove breakpoint goes through ->file children, but my filter links
> active disk as ->backing. So, before block-job start we can insert breakpoint
> by device name. But then, when filter inserted, we can't remove breakpoint,
> because my filter hides blkdebug with active disk under ->backing link.
> 
> Maybe, right solution would be support backing links in bdrv_debug_breakpoint()
> and bdrv_debug_remove_breakpoint() for the case when there is no file child.
> 
> But being unsure about right behavior, I've decided to adjust the test.
> 
> What about just do both  add/remove breakpoint through blkdebug node-name, to
> make it less weird?

Yes, I was mostly wondering about the "set constant name for
breakpoints".  It doesn't seem necessary to me; if you use node names,
you could address the blkdebug node directly, I would think.

Max

>> Wouldn't it be better to let the user specify the breakpoint name?
> 
> it's not needed now. with current naming we can have one break-point in device,
> so we don't need different names.
> 
>>
>> Max
>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>>> ---
>>>   tests/qemu-iotests/iotests.py | 9 +++++----
>>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
>>> index 76877ad584..c9779f432f 100644
>>> --- a/tests/qemu-iotests/iotests.py
>>> +++ b/tests/qemu-iotests/iotests.py
>>> @@ -415,11 +415,11 @@ class VM(qtest.QEMUQtestMachine):
>>>               self.pause_drive(drive, "write_aio")
>>>               return
>>>           self.qmp('human-monitor-command',
>>> -                    command_line='qemu-io %s "break %s bp_%s"' % (drive, event, drive))
>>> +                    command_line='qemu-io %s "break %s bp_0"' % (drive, event))
>>>   
>>>       def resume_drive(self, drive):
>>>           self.qmp('human-monitor-command',
>>> -                    command_line='qemu-io %s "remove_break bp_%s"' % (drive, drive))
>>> +                    command_line='qemu-io %s "remove_break bp_0"' % (drive))
>>>   
>>>       def hmp_qemu_io(self, drive, cmd):
>>>           '''Write to a given drive using an HMP command'''
>>> @@ -543,13 +543,14 @@ class QMPTestCase(unittest.TestCase):
>>>           self.assertEqual(self.vm.flatten_qmp_object(json.loads(json_filename[5:])),
>>>                            self.vm.flatten_qmp_object(reference))
>>>   
>>> -    def cancel_and_wait(self, drive='drive0', force=False, resume=False):
>>> +    def cancel_and_wait(self, drive='drive0', force=False, resume=False,
>>> +                        resume_node=None):
>>>           '''Cancel a block job and wait for it to finish, returning the event'''
>>>           result = self.vm.qmp('block-job-cancel', device=drive, force=force)
>>>           self.assert_qmp(result, 'return', {})
>>>   
>>>           if resume:
>>> -            self.vm.resume_drive(drive)
>>> +            self.vm.resume_drive(resume_node or drive)
>>>   
>>>           cancelled = False
>>>           result = None
>>>
>>
>>
> 
> 



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

  reply	other threads:[~2019-01-16 13:11 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-29 12:20 [Qemu-devel] [PATCH v5 00/11] backup-top filter driver for backup Vladimir Sementsov-Ogievskiy
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 01/11] block/backup: simplify backup_incremental_init_copy_bitmap Vladimir Sementsov-Ogievskiy
2019-01-14 13:10   ` Max Reitz
2019-01-14 13:13     ` Max Reitz
2019-01-14 14:01     ` Vladimir Sementsov-Ogievskiy
2019-01-14 14:13       ` Max Reitz
2019-01-14 14:48         ` Vladimir Sementsov-Ogievskiy
2019-01-16 13:05           ` Max Reitz
2019-01-23  8:20             ` Vladimir Sementsov-Ogievskiy
2019-01-23 13:19               ` Max Reitz
2019-01-23 14:36               ` Eric Blake
2019-01-24 14:20                 ` Vladimir Sementsov-Ogievskiy
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 02/11] block/backup: move to copy_bitmap with granularity Vladimir Sementsov-Ogievskiy
2019-01-14 14:10   ` Max Reitz
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 03/11] block: improve should_update_child Vladimir Sementsov-Ogievskiy
2019-01-14 14:32   ` Max Reitz
2019-01-14 16:13     ` Vladimir Sementsov-Ogievskiy
2019-01-16 13:17       ` Max Reitz
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 04/11] iotests: handle -f argument correctly for qemu_io_silent Vladimir Sementsov-Ogievskiy
2019-01-14 14:36   ` Max Reitz
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 05/11] iotests: allow resume_drive by node name Vladimir Sementsov-Ogievskiy
2019-01-14 14:46   ` Max Reitz
2019-01-14 16:06     ` Vladimir Sementsov-Ogievskiy
2019-01-16 13:11       ` Max Reitz [this message]
2019-01-23 13:22         ` Vladimir Sementsov-Ogievskiy
2019-01-23 13:31           ` Vladimir Sementsov-Ogievskiy
2019-01-23 13:33             ` Max Reitz
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 06/11] iotests: prepare 055 to graph changes during backup job Vladimir Sementsov-Ogievskiy
2019-01-16 13:48   ` Max Reitz
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 07/11] block: introduce backup-top filter driver Vladimir Sementsov-Ogievskiy
2019-01-16 16:02   ` Max Reitz
2019-01-17 12:13     ` Vladimir Sementsov-Ogievskiy
2019-01-18 12:05       ` Max Reitz
2019-01-23 13:47         ` Vladimir Sementsov-Ogievskiy
2019-04-13 16:08     ` Vladimir Sementsov-Ogievskiy
2019-04-13 16:08       ` Vladimir Sementsov-Ogievskiy
2019-04-13 17:03       ` Vladimir Sementsov-Ogievskiy
2019-04-13 17:03         ` Vladimir Sementsov-Ogievskiy
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 08/11] block/io: refactor wait_serialising_requests Vladimir Sementsov-Ogievskiy
2019-01-16 16:18   ` Max Reitz
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 09/11] block: add lock/unlock range functions Vladimir Sementsov-Ogievskiy
2019-01-16 16:36   ` Max Reitz
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 10/11] block/backup: tiny refactor backup_job_create Vladimir Sementsov-Ogievskiy
2019-01-18 13:00   ` Max Reitz
2018-12-29 12:20 ` [Qemu-devel] [PATCH v5 11/11] block/backup: use backup-top instead of write notifiers Vladimir Sementsov-Ogievskiy
2019-01-18 14:56   ` Max Reitz
2019-01-28 11:29     ` Vladimir Sementsov-Ogievskiy
2019-01-28 15:59       ` Max Reitz
2019-01-28 16:44         ` Vladimir Sementsov-Ogievskiy
2019-01-28 16:53           ` Max Reitz
2019-01-28 17:14             ` Vladimir Sementsov-Ogievskiy
2019-01-28 17:40           ` Kevin Wolf
2019-01-28 19:00             ` Vladimir Sementsov-Ogievskiy
2019-01-23 15:26 ` [Qemu-devel] [PATCH v5 00/11] backup-top filter driver for backup no-reply

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=fab4d292-ea59-5e1f-ec43-486abc455e7c@redhat.com \
    --to=mreitz@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=eblake@redhat.com \
    --cc=fam@euphon.net \
    --cc=jcody@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.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.