qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm fo


From: Thorsten Kohfeldt
Subject: Re: [Qemu-devel] [PATCH] hmp: Improve 'info mtree' with optional parm for mapinfo
Date: Tue, 20 Sep 2016 22:18:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0


Am 20.09.2016 um 20:46 schrieb Laszlo Ersek:
On 09/20/16 20:23, Thorsten Kohfeldt wrote:

Am 20.09.2016 um 02:51 schrieb Laszlo Ersek:

I think it would make sense to work from the pre-rendered FlatView,
if the information you can get out of it covers your needs.

I assume you know by now that I do _not_ feel that it covers my needs.

Okay. I guess you've made your point convincingly enough (although I'm
just an interested bystander in this thread). I think the patch has a
very low chance for regressions and it shouldn't draw in a big
maintenance burden, so it could be considered "pure improvement" as-is.

I'm not volunteering to do a full review. One thing I notice though is
that the constification of memory_region_size()'s sole parameter could
be / should be moved into a separate, "prep" patch.

I am really not having the attitude of unwillingness to listen to suggestions.
But this was my train of thoughts towards that split up (before I posted):
1) This (split up) moves the patch suite size from 1 file to 3 files.
2) It now requires an aditional cover letter, a trivial patch and the actual 
patch.
3) If the trivial patch was applied but not the actual patch,
   I'd have to maintain 2 variants of the actual patch to fit current and
   also older trees (with and without constant local mr pointer variable).
And this comes on top since 2b9e35760a8ff5548f6789d048c6e6e3c22c70ee
4) Well, that would be even more, as I have to maintain 2 variants already 
anyway:
   V2.6/V2.7 and master.

Having that stated, of course I am willing to follow your suggestion
anyway to get this through if it is insisted upon.

(I propose you wait for further feedback before reposting just with this
change.)

I'm gladly looking forward to decisive guidance.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]