Messages in this thread | | | Subject | Re: [PATCH 00/11] trace-cmd: make libtracecmd a linkable object | From | Josef Bacik <> | Date | Mon, 21 Nov 2016 15:06:24 -0500 |
| |
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
| |