From: Eduardo Habkost <ehabkost@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, crosa@redhat.com,
eblake@redhat.com, armbru@redhat.com, mreitz@redhat.com,
kwolf@redhat.com, famz@redhat.com, jsnow@redhat.com,
den@openvz.org, stefanha@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/4] scripts/qemu: add render_block_graph method for QEMUMachine
Date: Fri, 17 Aug 2018 10:47:27 -0300 [thread overview]
Message-ID: <20180817134727.GC15372@localhost.localdomain> (raw)
In-Reply-To: <deec540b-aaf7-4f8d-5c9f-0684fb2b9b34@virtuozzo.com>
On Fri, Aug 17, 2018 at 01:08:42PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 17.08.2018 04:54, Eduardo Habkost wrote:
> > On Thu, Aug 16, 2018 at 08:20:26PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> > > Render block nodes graph with help of graphviz
> > >
> > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> > Thanks for your patch. Comments below:
> >
> > > ---
> > > scripts/qemu.py | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 53 insertions(+)
> > >
> > > diff --git a/scripts/qemu.py b/scripts/qemu.py
> > > index f099ce7278..cff562c713 100644
> > > --- a/scripts/qemu.py
> > > +++ b/scripts/qemu.py
> > > @@ -460,3 +460,56 @@ class QEMUMachine(object):
> > > socket.SOCK_STREAM)
> > > self._console_socket.connect(self._console_address)
> > > return self._console_socket
> > > +
> > > + def render_block_graph(self, filename):
> > > + '''
> > > + Render graph in text (dot) representation into "filename" and graphical
> > > + representation into pdf file "filename".pdf
> > > + '''
> > > +
> > > + try:
> > > + from graphviz import Digraph
> > I'm not convinced that this belongs to qemu.py, if most code
> > using the qemu.py module will never use it. Do you see any
> > problem in moving this code to a scripts/render_block_graph.py
> > script?
>
> Not a problem, I can do it.. Just one thought:
> Isn't it better to keep all function doing something with one vm as methods,
> not separate functions?
I don't think so. We don't need to create a new QEMUMachine
method every time we write a function that takes a QEMUMachine as
argument in our scripts.
There are cases when we're forced to create a method: when the
new code is tightly coupled to the QEMUMachine code and need
access to its private attributes.
There are cases where we probably want to place the code in
qemu.py (as a method): when we expect many users of qemu.py to
call it.
But in other cases, I don't see any problem with another
script/module having a regular function like:
def my_special_purpose_function(vm, ...):
...
--
Eduardo
next prev parent reply other threads:[~2018-08-17 13:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-16 17:20 [Qemu-devel] [PATCH 0/4] block nodes graph visualization Vladimir Sementsov-Ogievskiy
2018-08-16 17:20 ` [Qemu-devel] [PATCH 1/4] block: improve blk_root_get_parent_desc Vladimir Sementsov-Ogievskiy
2018-08-16 17:35 ` Vladimir Sementsov-Ogievskiy
2018-08-16 17:20 ` [Qemu-devel] [PATCH 2/4] qapi: add x-query-block-nodes-relations Vladimir Sementsov-Ogievskiy
2018-08-16 17:20 ` [Qemu-devel] [PATCH 3/4] scripts/qemu: add render_block_graph method for QEMUMachine Vladimir Sementsov-Ogievskiy
2018-08-17 1:54 ` Eduardo Habkost
2018-08-17 10:08 ` Vladimir Sementsov-Ogievskiy
2018-08-17 13:47 ` Eduardo Habkost [this message]
2018-08-16 17:20 ` [Qemu-devel] [PATCH 4/4] not-for-commit: example of new command usage for debugging Vladimir Sementsov-Ogievskiy
2018-08-16 17:22 ` [Qemu-devel] [PATCH 0/4] block nodes graph visualization Vladimir Sementsov-Ogievskiy
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=20180817134727.GC15372@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=armbru@redhat.com \
--cc=crosa@redhat.com \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@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 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).