Subject: Re: [PATCH 00/11] trace-cmd: make libtracecmd a linkable object
To: Steven Rostedt <rostedt@goodmis.org>
References: <1448053053-24188-1-git-send-email-jbacik@fb.com>
 <20161121121312.6e5a2169@gandalf.local.home>
CC: <kernel-team@fb.com>, <linux-kernel@vger.kernel.org>
From: Josef Bacik <jbacik@fb.com>
Message-ID: <4f615915-7748-0ff7-4771-a1fca447d551@fb.com>
Date: Mon, 21 Nov 2016 15:06:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20161121121312.6e5a2169@gandalf.local.home>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Nov 2016 20:06:30.1305 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1324
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-21_13:,,
 signatures=0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2769
Lines: 50

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