Re: [PATCH] xentrace: add a tool to break down the result of vmexit

[George Dunlap <george.dunlap@eu.citrix.com>]

On 19/08/13 15:26, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH] xentrace: add a tool to break down the result of vmexit"):
>> On Fri, Aug 9, 2013 at 2:28 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>>> On Fri, Aug 09, 2013 at 10:10:19AM +0100, George Dunlap wrote:
>>>> I'm not sure what it would take to get it checked into the main
>>>> repo.  At the moment the code is just one massive file (with a
>>>> couple of helper files), and no doubt has a number of coding style
>>>> inconsistencies - though I there is certainly worse code in the
>>>> tree. :-)
> I think there is no problem introducing it into the main tree.
>
> If we reach consensus, I would be happy to do that as a subtree merge
> followed by adjustments to the build machinery.  (So we would import
> with a git version of the existing history.)
>
> Things that I think might need attention and haven't seen discussed
> are:
>
> 1. Build system.  Can it easily be plumbed into the build system for
>     tools ?

There shouldn't be a major problem integrating it into the build system.

One issue at the moment is that it requires the GNU arg parsing library, 
so it would either need to be ported to the older POSIX arg parsing 
stuff to build on BSD, or just be disabled on systems without it.  I 
would prefer the second, because I think the GNU library is much 
better.  But I don't know the policy for the tools tree.  (Christoph 
Egger may want to make a case for moving to the POSIX arg parsing library.)

> 2. Copyright.  Does the xenalyse history contain good copyright
>     information for all the code ?

Yes.  It was developed entirely by myself, while working for Citrix, 
until the time that I made it public; after that time I required the 
standard Signed-off-by's (and included them in my own commits).

>
>>> My opinion is that it should have the same treatment as any new
>>> code added - adhere to the StyleGuide.
> I don't think we should block addition of new code under a new tools/
> directory for style reasons.  tools/ is already full of code under a
> variety of different styles.  Our practice has been to insist that
> each directory has a single style, and to expect changes to maintain
> the style of existing code.

It's mostly consistent with the hypervisor style, but tended to drift a 
bit when I started doing more coding for the toolstack.  :-/

>> If it requires many changes, I won't personally have time to get to it
>> this release cycle.  If anyone else wanted to clean it up and submit
>> on the other hand... :-)
> Do you have it in the form of a git tree we could merge ?

It's in mercurial at the moment.  I'm sure it wouldn't be too hard to do 
a one-time translation into git which you could then pull.

  -George