[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxx> 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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.