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
