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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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