[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 01/12] libqos/qgraph: add qemu_name to QOSGraphNode
From: |
Christian Schoenebeck |
Subject: |
Re: [PATCH v4 01/12] libqos/qgraph: add qemu_name to QOSGraphNode |
Date: |
Sat, 24 Oct 2020 12:39:35 +0200 |
On Samstag, 24. Oktober 2020 08:08:59 CEST Thomas Huth wrote:
> On 19/10/2020 12.35, Christian Schoenebeck wrote:
> > On Donnerstag, 8. Oktober 2020 20:34:56 CEST Christian Schoenebeck wrote:
> >> Add new member variable 'qemu_name' to struct QOSGraphNode.
> >>
> >> This new member may be optionally set in case a different
> >> name for the node (which must always be a unique name) vs.
> >> its actually associated QEMU (QMP) device name is required.
> >>
> >> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> >> ---
> >>
> >> tests/qtest/libqos/qgraph.c | 1 +
> >> tests/qtest/libqos/qgraph_internal.h | 1 +
> >> 2 files changed, 2 insertions(+)
> >
> > So what shall happen with these libqos patches 1..7? Is that a nack, or
> > postpone for now?
>
> I was hoping to see a review by Paolo or Laurent, who are much more familiar
> with qos than I am ... but after having a look at the patches, I think I
> can also give some feedback, too:
>
> Patch 1 and 2 sound basically ok to me (should maybe be squashed together,
> though), but the qos_node_create_driver_named() function currently seems to
> be unused so far? So I'd postpone these two patches to the point in time
> when you really need the qos_node_create_driver_named() function.
I did use patches 1 & 2 in v1 of this series, as of v2 and higher I used a
workaround for the actual 9pfs test case patches not to depend on these 2
libqos patches. This happened after Paolo's feedback, who wrote that qos
patches 1 & 2 would be useful for other, future use cases, but argued it
would not be appropriate for my intended use case:
https://lore.kernel.org/qemu-devel/95ef57d0-b35e-f16a-f957-06bc3692cb7c@redhat.com/
I preserved patches 1 & 2 in this series though as he noted they might be
useful for future purposes and applied his requested changes. I personally
probably won't need thise 2 patches any time soon. So it's up to you what
shall happen with them. I don't mind if you postpone or nack them.
> The other patches are basically fine with me, too, but please avoid the
> hard-coded ESC codes that only work with certain terminals.
>
> Thomas
I'll respond to that on your patch 4 response.
Best regards,
Christian Schoenebeck
[PATCH v4 05/12] tests/qtest/qos-test: dump qos graph if verbose, Christian Schoenebeck, 2020/10/08