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]

Message-ID: <20161121121312.6e5a2169@gandalf.local.home>
Date:   Mon, 21 Nov 2016 12:13:12 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Josef Bacik <jbacik@...com>
Cc:     <kernel-team@...com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/11] trace-cmd: make libtracecmd a linkable object

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.

-- Steve