Re: [Xen-devel] (no subject)

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 07/07/16 12:03, Dario Faggioli wrote:
> On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
>> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
>> <dario.faggioli@xxxxxxxxxx> wrote:
>>>
>>> in both xenalyze and formats (for xentrace_format).
>>>
>>> In particular, in xenalyze, now that we have the precision
>>> of the fixed point load values in the tracepoint, show both
>>> the raw value and the (easier to interpreet) percentage.
>>>
>>> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
>> The change looks good in itself; but it makes me realize that
>> technically by changing the trace format, the previous patch
>> introduced a regression which is fixed here.  There's a part of me
>> that's tempted to overlook it because it's minor, but on balance I
>> think we should try to be diligent with this sort of thing.
>>
> Sure!
> 
>> Could you re-send this with the trace change moved from the previous
>> patch to this patch?
>>
> So, you're saying I should change both Xen, xentrace_format and
> xenalyze.c all at once, in the same patch, right?
> 
> I'm asking just to double check, as, although I see your point,
> separating things by component seemed a good thing to do to me, even at
> the price you describe, and I've done it before. :-)
> 
> As said, I'm fine doing that, I just want to be sure this is what you
> are asking.

I think it often does make sense to check things out by component.  And
of course before xenalyze was in tree, it doesn't matter when the change
was done.  I suppose I've always been prejudiced against
xentrace_format, which is why I'd never thought about regressions in it
(although I probably should have).

But now that xenalyze is in-tree, I think we want to avoid situations
where the in-tree xenalyze is broken, even just for one changeset, if we
can avoid it.

Thanks,
 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel