From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wrgHHerqp2DzAgAAWB0awg (envelope-from ) for ; Fri, 21 May 2021 13:16:26 -0400 Received: by simark.ca (Postfix, from userid 112) id 67B031F11C; Fri, 21 May 2021 13:16:26 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1A09F1E783 for ; Fri, 21 May 2021 13:16:26 -0400 (EDT) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4FmtYj6gM9z1slQ for ; Fri, 21 May 2021 13:16:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1621617385; bh=ktObnXIWhFRJAk8xjPYGS4roKbuweMUgofsi5EZKW7s=; h=Date:To:Cc:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=S8yRXZDRBpldTFsYaRteX/VXYUW3N6ae/vekGcTOVPYhgEvWL8ga8wi6YHLecM7FO 1NcEf/DIjTIbW753bfy+hTDs5eUGfpjV7wGBlZCsP2uBKMqfh6B9Ly/tCWvg2g8NsN EXyV+U5oRpPppttSWslgCasJW25SbBeOM9Tr3LY7jb7Z7TmTJLjCUpG8xmTuX0XeZW wqI76JoQCJ3f1kIBdFCVRBtFYuShCWsA8IVKFtTqJXYJKEd/XvY28Myt1JLESdISh+ mEX4z2v1aVfC4CEb58TysQavtjhchDxxE7JWJWtpGNj8lfw4BoCC2Q+KiZUYxDYjgB SeAzGQuY1AFRw== Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by lists.lttng.org (Postfix) with ESMTPS id 4FmqR72rRRz1scb for ; Fri, 21 May 2021 10:55:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 2F3A43478EB for ; Fri, 21 May 2021 10:55:24 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id FKHIp7Ggoeoz; Fri, 21 May 2021 10:55:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 26EAB3478EA; Fri, 21 May 2021 10:55:23 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 26EAB3478EA X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ufw4DuGKRTPz; Fri, 21 May 2021 10:55:23 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 1AF7B347B64; Fri, 21 May 2021 10:55:23 -0400 (EDT) Date: Fri, 21 May 2021 10:55:22 -0400 (EDT) To: Norbert Lange Cc: lttng-dev Message-ID: <1296448182.54074.1621608922994.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20210520121807.55428-1-nolange79@gmail.com> <982122605.52445.1621524098787.JavaMail.zimbra@efficios.com> <523808152.52514.1621527935563.JavaMail.zimbra@efficios.com> <154847626.52635.1621531127222.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_4018 (ZimbraWebClient - FF88 (Linux)/8.8.15_GA_4007) Thread-Topic: Improve tracelog handling, reduce exported functions Thread-Index: LWqpCTCYXU1Fj5X5nxkM2wsa6LrLpg== Subject: Re: [lttng-dev] [PATCH lttng-ust] Improve tracelog handling, reduce exported functions X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mathieu Desnoyers via lttng-dev Reply-To: Mathieu Desnoyers Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" ----- On May 20, 2021, at 1:43 PM, Norbert Lange nolange79@gmail.com wrote: > Am Do., 20. Mai 2021 um 19:18 Uhr schrieb Mathieu Desnoyers > : >> >> >> >> ----- On May 20, 2021, at 12:51 PM, Norbert Lange nolange79@gmail.com wrote: >> >> > Am Do., 20. Mai 2021 um 18:25 Uhr schrieb Mathieu Desnoyers >> > : >> >> >> >> ----- On May 20, 2021, at 11:54 AM, Norbert Lange nolange79@gmail.com wrote: >> >> [...] >> >> >> >> >> What prevents you from linking against lttng-ust.so again ? >> >> > >> >> > I did not poke around enough with Lttng to be confident it wont have >> >> > side effects, >> >> > I really don't want it active in production. It doesn't seem there is >> >> > much public knowledge with Xenomai either. >> >> > lttng-ust.so will spawn threads, lttng-ust-tracepoint.so is mostly passive, >> >> >> >> There is indeed a split between instrumentation and runtime threads done >> >> with lttng-ust-tracepoint.so vs lttng-ust.so. >> >> >> >> I understand that this split is missing for tracelog and tracef, and >> >> would be a good thing to have. >> >> >> >> I would be interested to move the tracelog and tracef implementation >> >> from liblttng-ust.so to liblttng-ust-tracepoint.so, even this late >> >> in the -rc cycle, because all users of tracelog/tracef need to link >> >> against liblttng-ust-tracepoint.so anyway. So moving these symbols >> >> should not affect anyone. >> >> >> >> Can you give it a try and let me know if it works for you ? >> > >> > Will take some time, whats the timeframe you need for feedback? >> >> Here is the tentative commit: >> >> https://review.lttng.org/c/lttng-ust/+/5927 Move tracef/tracelog symbols to >> liblttng-ust-tracepoint.so > > Well... this is certainly an improvement. I am not completely happy > though: "... users now link against > liblttng-ust-tracepoint.so explicitly" I'm abandoning this change for now. It's too late in the rc cycle for doing an ABI breaking change. Also, this can eventually be done gradually by introducing a new .so with new symbols, and mapping the tracelog/tracef APIs to those new symbols in a future release. So I don't think it justifies breaking ABI at this stage. > > My homecooked solution currently works like this: > > *) define the probes from with > TRACEPOINT_PROBE_DYNAMIC_LINKAGE, > link them in the application, together with other dynamic probes > *) build a separate library with *other* tracepoints, lets call it > libtracepoint.so > *) don't link the application to any lttng library. > > Which means: > > 1) the application works without lttng libraries. tracepoints are no-ops > 2) if available then liblttng-ust-tracepoint.so is loaded (constructor > function from your headers). tracepoints are no-ops > 3) if the application dlopen's libtracepoint.so and in turn > liblttng-ust.so then tracepoints work. > > I'd lose option 1 compared to reimplementing tracelog using homecooked > lttng-ust-tracelog tracepoints. > > So, are there any issues using that way, > it seems to work fine, > are there mutliple competing instances now? > (I am not re-using any bit from tracelog.h, I am just after using the > tracepoint definition). > > I mean I could dlsym all the functions, but tracelog has 1 per > loglevel and really ugly long names ;) I recommend that you re-use the parts of tracelog which are useful to you, but that you implement your own events within your provider .so with your own event names, so there is no clash with upstream lttng-ust. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev