On 04/03/20 09:06, Zhang, Chen wrote:
> Hi Eric and Paolo, Can you give some comments about this series?
>
>
No news for a while...
We already have some users(Cloud Service Provider) try to use is module in their
product.
But they also need to follow the Qemu upstream code.
My main comment about this series is that it's not clear why it is
needed and how to use it. The documentation includes a demo, but no
description of what is an awd_node, a notification_node and an
opt_script. I can more or less understand the notification_node and
opt_script role from the documentation, but not entirely because, for
example, the two-host demo has hardcoded IP addresses without saying
which host is which IP address.
The documentation does not describe the protocol, which is absolutely
necessary, and does not describe _why_ the protocol was designed like
that. Without such documentation it's not clear if, for example, the
watchdog protocol could be implemented as QMP commands (e.g.
start-watchdog, stop-watchdog, notify-watchdog). Another possibility
could be to use the systemd watchdog protocol, which consists of
essentially three commands (WATCHDOG=1, WATCHDOG=trigger,
WATCHDOG_USEC=...) which are transmitted as datagrams. Documentation is
important for reviewers to judge the merits of the protocol without (or
before) diving into the code.
In the demo, the opt_script mechanism is currently using the "human"
monitor as opposed to QMP. The human monitor interface is not stable
and not meant for consumption by management interface. It is not clear
if this is just a sample usage, and in practice the notification_node
would be outside of QEMU, or not. In general I would prefer to have the
script as an optional feature, and report the triggering of the watchdog
via QMP events.
Paolo