Re: [PATCH v4 00/13] tools/xenstore: rework internal accounting

[Julien Grall <julien@xxxxxxx>]

Hi Juergen,

On 26/04/2023 08:19, Juergen Gross wrote:
> On 05.04.23 09:03, Juergen Gross wrote:
> > This series reworks the Xenstore internal accounting to use a uniform
> > generic framework. It is adding some additional useful diagnostic
> > information, like accounting trace and max. per-domain and global quota
> > values seen.
> >
> > Changes in V2:
> > - added patch 1 (leftover from previous series)
> > - rebase
> >
> > Changes in V3:
> > - addressed comments
> >
> > Changes in V4:
> > - fixed patch 3
> Another thought for this series and followup one:
>
> Do we want to keep current coding style in tools/xenstore (basically
> Linux kernel style), or do we want to switch to Xen style instead?
I am a bit split on this one. I don't particularly like the Linux coding 
style, but it has the advantage to be well-documented (if we compare to 
the Xen one).
May I ask what would be the reason to switch?

> If a switch to Xen style is preferred (I do prefer that switch), I'd
> like to suggest that I do a rework of this series and the followup one
> to use the Xen style for new or moved functions.
I think this is a bad idea because it would make difficult for a 
developer/reviewer to know what is the coding style of a given function.
At least in my workflow, it would also means that I need two open the 
file twice with different settings (e.g. soft vs hard tab).
> A more radical approach would be to do a large style switch series
> after the two series, but I'm hesitant as this would affect backports
> rather badly.
In general, I would agree with that. But, after your work, I am under 
the impression that Xenstored will become quite different. So I am not 
convince we will be able to backports a lot of patch without significant 
rework.
Therefore, converting all the files in one pass may not be too bad 
(assuming we agree on switching to the new coding style).
Cheers,

--
Julien Grall