[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4f615915-7748-0ff7-4771-a1fca447d551@fb.com>
Date: Mon, 21 Nov 2016 15:06:24 -0500
From: Josef Bacik <jbacik@...com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: <kernel-team@...com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/11] trace-cmd: make libtracecmd a linkable object
On 11/21/2016 12:13 PM, Steven Rostedt wrote:
> On Fri, 20 Nov 2015 15:57:22 -0500
> Josef Bacik <jbacik@...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
Powered by blists - more mailing lists