From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Cc: qemu-devel@nongnu.org, marcandre.lureau@gmail.com,
mdroth@linux.vnet.ibm.com, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 0/6] QGA: systemd hibernate/suspend/hybrid-sleep
Date: Thu, 21 Jun 2018 18:19:09 -0300 [thread overview]
Message-ID: <9209353e-4867-bee1-efe5-6ba92f49ef2f@gmail.com> (raw)
In-Reply-To: <20180621201923.GA27759@kermit-br-ibm-com>
Hi,
On 06/21/2018 05:19 PM, Murilo Opsfelder Araujo wrote:
> On Thu, Jun 21, 2018 at 07:21:47AM -0300, Daniel Henrique Barboza wrote:
>> changes in v2 from Marc-Andre Lureau review:
>> - use error_free() accordingly
>> - use g_spawn_sync() instead of fork() in run_process_child()
>> - previous version link:
>> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg05499.html
>>
>>
>> This series adds systemd suspend support for QGA. Some newer
>> guests don't have pmutils anymore, leaving us with just the
>> Linux state file mechanism to suspend the guest OS, which does
>> not support hybrid-sleep. With this implementation, QGA is
>> now able to hybrid suspend newer guests again.
>>
>> Most of the patches are cleanups in the existing suspend code,
>> aiming at both simplifying it and making it easier to extend
>> it with systemd.
>>
>>
>> Daniel Henrique Barboza (6):
>> qga: refactoring qmp_guest_suspend_* functions
>> qga: bios_supports_mode: decoupling pm-utils and sys logic
>> qga: guest_suspend: decoupling pm-utils and sys logic
>> qga: removing switch statements, adding run_process_child
>> qga: systemd hibernate/suspend/hybrid-sleep support
>> qga: removing bios_supports_mode
> Hi, Daniel.
>
> Your patches look good, just some minor comments about how they're
> organized and coding style, if you allow me.
>
> I'd suggest to introduce the new API, functions, and typedef at first
> (preferably one thing per patch to easier the review) without wiring
> them up.
>
> After the new stuff is ready to use, I'd wire them up (one per patch)
> and update/remove old API they're replacing.
>
> Introducing the new API and wiring it up later makes it easier to
> review. For example, bios_supports_mode() is changed by patch 1/6, then
> it's moved around by patch 3/6, and finally removed by patch 6/6.
The idea was to present the patches as incremental cleanups from
the existing code up to the point where the new API can be gracefully
added.
I think there's a point to be made about squashing all cleanups patches
in a single (or fewer) patches, but I believe it would be too annoying to
review that many changes at once - things started very coupled with
QMP functions hard-wiring pmutils binaries as parameters to the callers
(bios_support_mode and guest_suspend). If you compare that to the
result up to patch 4/6 you'll see that a lot was changed, and systemd
support was yet to be added.
Following the same incremental idea, patch 6/6 was created after I've
noticed that bios_support_mode was too sub-optimal after adding systemd
support. Yes, one can say that it was already sub-optimal before and it
should be removed right at the start, but I didn't bothered with this
change at that point due to other cleanups.
Anyway, if more people feels like the series structure should be changed
I can re-send the series again.
>
> Do we need an empty line after opening a switch statement? I'd drop it,
> as seen in other parts of the code.
Didn't noticed it. If I end up respinning this series I'll remove it.
>
> Does run_process_child() fit better under util/, or another place where
> it can be shared throughout the code, if that's the case?
As I've mentioned in the commit message of patch 5/6, one step at a
time. If the function can be used in other places inside commands-posix.c
(IMO a fair assumption, but I didn't look it up carefully), then we could
first use this new function inside commands-posix.c and, if the function
turns out to be useful elsewhere, moved it to /util.
I didn't want to sound "pretentious" by adding a new function to /util
just because it is being used by the code I'm sending and because I
have a hunch that it will be useful to everyone else.
Thanks,
Daniel
>
> Cheers
> Murilo
>
prev parent reply other threads:[~2018-06-21 21:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-21 10:21 [Qemu-devel] [PATCH v2 0/6] QGA: systemd hibernate/suspend/hybrid-sleep Daniel Henrique Barboza
2018-06-21 10:21 ` [Qemu-devel] [PATCH v2 1/6] qga: refactoring qmp_guest_suspend_* functions Daniel Henrique Barboza
2018-06-21 10:21 ` [Qemu-devel] [PATCH v2 2/6] qga: bios_supports_mode: decoupling pm-utils and sys logic Daniel Henrique Barboza
2018-06-21 10:21 ` [Qemu-devel] [PATCH v2 3/6] qga: guest_suspend: " Daniel Henrique Barboza
2018-06-21 10:21 ` [Qemu-devel] [PATCH v2 4/6] qga: removing switch statements, adding run_process_child Daniel Henrique Barboza
2018-06-21 10:21 ` [Qemu-devel] [PATCH v2 5/6] qga: systemd hibernate/suspend/hybrid-sleep support Daniel Henrique Barboza
2018-06-21 10:21 ` [Qemu-devel] [PATCH v2 6/6] qga: removing bios_supports_mode Daniel Henrique Barboza
2018-06-21 20:19 ` [Qemu-devel] [PATCH v2 0/6] QGA: systemd hibernate/suspend/hybrid-sleep Murilo Opsfelder Araujo
2018-06-21 21:19 ` Daniel Henrique Barboza [this message]
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=9209353e-4867-bee1-efe5-6ba92f49ef2f@gmail.com \
--to=danielhb413@gmail.com \
--cc=armbru@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=muriloo@linux.ibm.com \
--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).