Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain context

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.04.2020 17:20, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: 30 March 2020 11:54
>> To: Paul Durrant <paul@xxxxxxx>
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Ian Jackson <ian.jackson@xxxxxxxxxxxxx>; 
>> Wei Liu <wl@xxxxxxx>
>> Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
>>
>> On 27.03.2020 19:50, Paul Durrant wrote:
>>> This tools is analogous to 'xen-hvmctx' which presents HVM context.
>>> Subsequent patches will add 'dump' functions when new records are
>>> introduced.
>>>
>>> Signed-off-by: Paul Durrant <paul@xxxxxxx>
>>> ---
>>> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>>> Cc: Wei Liu <wl@xxxxxxx>
>>> ---
>>>  .gitignore           |   1 +
>>>  tools/misc/Makefile  |   4 ++
>>>  tools/misc/xen-ctx.c | 144 +++++++++++++++++++++++++++++++++++++++++++
>>
>> Is xen-ctx a good choice of a name, considering we already have not
>> only xen-hvmctx, but also xenctx? If the new functionality isn't a
>> good fit for either, perhaps its name would better reflect its
>> connection to save/restore records? xen-sr-dump looks pretty clumsy
>> to me, but still seems better than a name easily mixed up with
>> others.
> 
> How about xen-domctx?

Hmm, maybe. Seeing this is about PV pieces, xen-pvctx might also be
an option.

Jan