Re: [PATCH 00/11] trace-cmd: make libtracecmd a linkable object

[Josef Bacik]

On 11/21/2016 12:13 PM, Steven Rostedt wrote:
> On Fri, 20 Nov 2015 15:57:22 -0500
> Josef Bacik <jbacik@xxxxxx> wrote:
>
> > We use trace-cmd pretty extensively inside of Facebook for various things, such
> > as live gathering of statistics.  Currently this involves launching trace-cmd to
> > record data and then processing the information afterwards.  This makes
> > collection kind of a pain and doesn't allow us to catch longterm trends.  What
> > we really want to do is use the trace stream infrastructure to do live
> > collection of events without having to use disk space and rely on the recorder
> > to not crash.
> >
> > The other problem we have is that any time we want to create a new tool we
> > basically have to add it to our build of trace-cmd and deploy an entirely new
> > trace-cmd package.  This is not super great as we want to keep the amount of
> > modifications to the core trace-cmd tool to a minimum and would rather just
> > write our tools on the outside and link against libtracecmd.
> >
> > Enter these patches.  libtracecmd is already created to be linked against by the
> > internal trace-cmd tools, but isn't actually able to be linked against because
> > of various internal dependancies.  These patches take a pass at killing some of
> > these interdependancies and adding global functions for external tools to link
> > against.  I have ported one of our tools over to link against this library and
> > it works well.  If it would help I can post the tool as well as an example.
> >
> > I made the explicit decision to do as little as possible when decoupling some of
> > the internal dependancies.  Specifically libtracecmd pulls in trace-record, and
> > that is where the bulk of the thread management stuff is for trace-stream as
> > well as the buffer_instance and event enablement code.  It got pretty hairy
> > trying to tease all of these bits out into their own things so instead I just
> > pulled out the dependancies on trace-profile and trace-read so that libtracecmd
> > didn't end up looking exactly like trace-cmd.  Thanks,
>
> I know this is a year old (it's been on my todo list for some
> time :-/). Have you updated these at all? I'm going to pull in what I
> can, but will be making some changes. For one, since trace-cmd is GPL
> and libtracecmd is LGPL, I can't merge in all functions easily without
> going through proper licensing auditing.
>
> I'll look at what you did, and try to do the "hairy" stuff to make the
> library pretty much stand alone and not all trace-cmd. Specifically, it
> will remain LGPL and trace-cmd GPL.

I haven't updated them since I last posted them.  Bpf filled this gap for us so 
we've abandoned our trace-cmd based tools and just use trace-cmd itself for 
random debugging instead.  Thanks,

Josef