lkml.org 
[lkml]   [2016]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 00/11] trace-cmd: make libtracecmd a linkable object
From
Date
On 11/21/2016 12:13 PM, Steven Rostedt wrote:
> On Fri, 20 Nov 2015 15:57:22 -0500
> Josef Bacik <jbacik@fb.com> 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

\
 
 \ /
  Last update: 2016-11-21 21:44    [W:0.248 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site