Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761067AbbKTU5m (ORCPT ); Fri, 20 Nov 2015 15:57:42 -0500 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:60843 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758806AbbKTU5l (ORCPT ); Fri, 20 Nov 2015 15:57:41 -0500 From: Josef Bacik To: , , Subject: [PATCH 00/11] trace-cmd: make libtracecmd a linkable object Date: Fri, 20 Nov 2015 15:57:22 -0500 Message-ID: <1448053053-24188-1-git-send-email-jbacik@fb.com> X-Mailer: git-send-email 2.1.0 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-11-20_12:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2099 Lines: 35 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/