linux-kernel - [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-next>] [day] [month] [year] [list]

Date:	Fri, 20 Nov 2015 15:57:22 -0500
From:	Josef Bacik <jbacik@...com>
To:	<kernel-team@...com>, <linux-kernel@...r.kernel.org>,
	<rostedt@...dmis.org>
Subject: [PATCH 00/11] trace-cmd: make libtracecmd a linkable object

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,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/