Re: [lttng-dev] Patch for lttng tools to build on Mac OSX 10.11.6
On 2017-05-24 11:11, Jérémie Galarneau wrote: > > Good idea! It will certainly be less error-prone. > I added it to this [1] pull request since it's build system related. It was tested on macOS 10.12.4. Michael [1] https://github.com/lttng/lttng-tools/pull/91 ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] tracing page_faults with lttng?
Hi Milian, Are you running on an x86 processor? The pagefault tracepoints are called : x86_exceptions_page_fault_user, x86_exceptions_page_fault_kernel Can you see those tracepoints when you run: lttng list --kernel Thank you, Francis 2017-05-24 12:00 GMT-04:00 Milian Wolff: > Hey all, > > when I trace with perf, I can see page_faults occurring. But when I do > something like the following with lttng: > > lttng create > lttng enable-channel kernel -k > lttng enable-event -c kernel -k -a > lttng start > # trigger page faults > lttng stop > > then I do not see any page faults in tracecompass/babeltrace. What do I > need > to do to see those too? I'm aware that lttng comes with its own set of > tracepoints - i.e. it's not using the same tracepoints that perf knows > about. > But googling shows me e.g. this: > > https://lists.lttng.org/pipermail/lttng-dev/2013-April/019954.html > https://lists.lttng.org/pipermail/lttng-dev/2016-May/026033.html > > Which sounds like the feature should be available in lttng too? > > I'm using the ArchLinux packages in AUR, i.e. version 2.9.2 of LTTng and > kernel 4.10.13-1. > > Thanks > -- > Milian Wolff | milian.wo...@kdab.com | Software Engineer > KDAB (Deutschland) GmbH KG, a KDAB Group company > Tel: +49-30-521325470 > KDAB - The Qt Experts > ___ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > -- Francis Deslauriers Software developer EfficiOS inc. ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-modules] Fix: Add support for 4.9.27-rt18 kernel
Merged into master, 2.10, 2.9, 2.8. - On May 24, 2017, at 5:19 PM, Michael Jeanson mjean...@efficios.com wrote: > Signed-off-by: Michael Jeanson> --- > instrumentation/events/lttng-module/sched.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/instrumentation/events/lttng-module/sched.h > b/instrumentation/events/lttng-module/sched.h > index c68dd27..e6f36b1 100644 > --- a/instrumentation/events/lttng-module/sched.h > +++ b/instrumentation/events/lttng-module/sched.h > @@ -540,7 +540,8 @@ LTTNG_TRACEPOINT_EVENT(sched_stat_runtime, > ) > #endif > > -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0)) > +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0) || \ > + LTTNG_RT_KERNEL_RANGE(4,9,27,18, 4,10,0,0)) > /* > * Tracepoint for showing priority inheritance modifying a tasks > * priority. > -- > 2.7.4 -- 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
Re: [lttng-dev] [PATCH lttng-modules] Fix: update btrfs instrumentation for kernel 4.12
Merged into master, 2.10, 2.9, 2.8. - On May 23, 2017, at 9:46 PM, Michael Jeanson mjean...@efficios.com wrote: > See upstream commit 490b54d6fb75f6ffd0471ec58bb38a992e2b40cd > > Signed-off-by: Michael Jeanson> --- > instrumentation/events/lttng-module/btrfs.h | 48 - > 1 file changed, 47 insertions(+), 1 deletion(-) > > diff --git a/instrumentation/events/lttng-module/btrfs.h > b/instrumentation/events/lttng-module/btrfs.h > index ecaf382..72777bc 100644 > --- a/instrumentation/events/lttng-module/btrfs.h > +++ b/instrumentation/events/lttng-module/btrfs.h > @@ -83,7 +83,30 @@ LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__inode, > btrfs_inode_evict, > TP_ARGS(inode) > ) > > -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,11,0)) > +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0)) > + > +LTTNG_TRACEPOINT_EVENT(btrfs_get_extent, > + > + TP_PROTO(struct btrfs_root *root, struct btrfs_inode *inode, > + struct extent_map *map), > + > + TP_ARGS(root, inode, map), > + > + TP_FIELDS( > + ctf_integer(u64, root_objectid, root->root_key.objectid) > + ctf_integer(u64, ino, btrfs_ino(inode)) > + ctf_integer(u64, start, map->start) > + ctf_integer(u64, len, map->len) > + ctf_integer(u64, orig_start, map->orig_start) > + ctf_integer(u64, block_start, map->block_start) > + ctf_integer(u64, block_len, map->block_len) > + ctf_integer(unsigned long, flags, map->flags) > + ctf_integer(int, refs, refcount_read(>refs)) > + ctf_integer(unsigned int, compress_type, map->compress_type) > + ) > +) > + > +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,11,0)) > > LTTNG_TRACEPOINT_EVENT(btrfs_get_extent, > > @@ -152,6 +175,28 @@ LTTNG_TRACEPOINT_EVENT(btrfs_get_extent, > > #endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,10,0)) */ > > +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0)) > +LTTNG_TRACEPOINT_EVENT_CLASS(btrfs__ordered_extent, > + > + TP_PROTO(struct inode *inode, struct btrfs_ordered_extent *ordered), > + > + TP_ARGS(inode, ordered), > + > + TP_FIELDS( > + ctf_integer(ino_t, ino, inode->i_ino) > + ctf_integer(u64, file_offset, ordered->file_offset) > + ctf_integer(u64, start, ordered->start) > + ctf_integer(u64, len, ordered->len) > + ctf_integer(u64, disk_len, ordered->disk_len) > + ctf_integer(u64, bytes_left, ordered->bytes_left) > + ctf_integer(unsigned long, flags, ordered->flags) > + ctf_integer(int, compress_type, ordered->compress_type) > + ctf_integer(int, refs, refcount_read(>refs)) > + ctf_integer(u64, root_objectid, > + BTRFS_I(inode)->root->root_key.objectid) > + ) > +) > +#else > LTTNG_TRACEPOINT_EVENT_CLASS(btrfs__ordered_extent, > > TP_PROTO(struct inode *inode, struct btrfs_ordered_extent *ordered), > @@ -172,6 +217,7 @@ LTTNG_TRACEPOINT_EVENT_CLASS(btrfs__ordered_extent, > BTRFS_I(inode)->root->root_key.objectid) > ) > ) > +#endif > > LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__ordered_extent, > btrfs_ordered_extent_add, > > -- > 2.7.4 -- 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
Re: [lttng-dev] [PATCH lttng-modules] Fix: update ringbuffer for kernel 4.12
Merged into master, 2.10, 2.9, 2.8, thanks! - On May 23, 2017, at 9:45 PM, Michael Jeanson mjean...@efficios.com wrote: > flags removed from splice_pipe_desc in 4.12. > > See upstream commit f81dc7d7d5a2528f98f26a0b9406e822d0b35011 > > Signed-off-by: Michael Jeanson> --- > lib/ringbuffer/ring_buffer_splice.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/ringbuffer/ring_buffer_splice.c > b/lib/ringbuffer/ring_buffer_splice.c > index 0610caa..8d14666 100644 > --- a/lib/ringbuffer/ring_buffer_splice.c > +++ b/lib/ringbuffer/ring_buffer_splice.c > @@ -95,7 +95,9 @@ static int subbuf_splice_actor(struct file *in, > .pages = pages, > .nr_pages = 0, > .partial = partial, > +#if (LINUX_VERSION_CODE < KERNEL_VERSION(4,12,0)) > .flags = flags, > +#endif > .ops = _buffer_pipe_buf_ops, > .spd_release = lib_ring_buffer_page_release, > }; > -- > 2.7.4 -- 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
Re: [lttng-dev] [PATCH lttng-modules] Fix: update sched instrumentation for kernel 4.12
Merged into master, 2.10, 2.9, 2.8. Thanks, Mathieu - On May 23, 2017, at 9:45 PM, Michael Jeanson mjean...@efficios.com wrote: > See upstream commit b91473ff6e979c0028f02f90e40c844959c736d8 > > Signed-off-by: Michael Jeanson> --- > instrumentation/events/lttng-module/sched.h | 20 +++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/instrumentation/events/lttng-module/sched.h > b/instrumentation/events/lttng-module/sched.h > index e5066af..c68dd27 100644 > --- a/instrumentation/events/lttng-module/sched.h > +++ b/instrumentation/events/lttng-module/sched.h > @@ -540,7 +540,25 @@ LTTNG_TRACEPOINT_EVENT(sched_stat_runtime, > ) > #endif > > -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,37)) > +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0)) > +/* > + * Tracepoint for showing priority inheritance modifying a tasks > + * priority. > + */ > +LTTNG_TRACEPOINT_EVENT(sched_pi_setprio, > + > + TP_PROTO(struct task_struct *tsk, struct task_struct *pi_task), > + > + TP_ARGS(tsk, pi_task), > + > + TP_FIELDS( > + ctf_array_text(char, comm, tsk->comm, TASK_COMM_LEN) > + ctf_integer(pid_t, tid, tsk->pid) > + ctf_integer(int, oldprio, tsk->prio - MAX_RT_PRIO) > + ctf_integer(int, newprio, pi_task ? pi_task->prio - MAX_RT_PRIO > : tsk->prio - > MAX_RT_PRIO) > + ) > +) > +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,37)) > /* > * Tracepoint for showing priority inheritance modifying a tasks > * priority. > -- > 2.7.4 -- 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
[lttng-dev] tracing page_faults with lttng?
Hey all, when I trace with perf, I can see page_faults occurring. But when I do something like the following with lttng: lttng create lttng enable-channel kernel -k lttng enable-event -c kernel -k -a lttng start # trigger page faults lttng stop then I do not see any page faults in tracecompass/babeltrace. What do I need to do to see those too? I'm aware that lttng comes with its own set of tracepoints - i.e. it's not using the same tracepoints that perf knows about. But googling shows me e.g. this: https://lists.lttng.org/pipermail/lttng-dev/2013-April/019954.html https://lists.lttng.org/pipermail/lttng-dev/2016-May/026033.html Which sounds like the feature should be available in lttng too? I'm using the ArchLinux packages in AUR, i.e. version 2.9.2 of LTTng and kernel 4.10.13-1. Thanks -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-modules] Fix: ext3 was completely removed from the kernel in v4.3
Merged into master, 2.10, 2.9, 2.8, thanks! Mathieu - On May 23, 2017, at 9:43 PM, Michael Jeanson mjean...@efficios.com wrote: > Don't display the warning about missing ext3 headers on kernels >= 4.3 > > See upstream commit e31fb9e00543e5d3c5b686747d3c862bc09b59f3 > > Signed-off-by: Michael Jeanson> --- > probes/Kbuild | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/probes/Kbuild b/probes/Kbuild > index 664595d..fe869d0 100644 > --- a/probes/Kbuild > +++ b/probes/Kbuild > @@ -97,13 +97,15 @@ ifneq ($(CONFIG_EXT3_FS),) > ext3_dep = $(srctree)/fs/ext3/*.h > ext3_dep_check = $(wildcard $(ext3_dep)) > ext3 = $(shell \ > -if [ $(VERSION) -ge 4 -o \( $(VERSION) -eq 3 -a $(PATCHLEVEL) -ge 1 \) ] > ; > then \ > - if [ \( $(VERSION) -ge 4 -o \( $(VERSION) -eq 3 -a $(PATCHLEVEL) -ge 4 > \) > \) -a \ > --z "$(ext3_dep_check)" ] ; then \ > -echo "warn" ; \ > -exit ; \ > +if [ $(VERSION) -lt 4 -o \( $(VERSION) -eq 4 -a $(PATCHLEVEL) -lt 3 \) ] > ; > then \ > + if [ $(VERSION) -ge 4 -o \( $(VERSION) -eq 3 -a $(PATCHLEVEL) -ge 1 \) > ] > ; then \ > +if [ \( $(VERSION) -ge 4 -o \( $(VERSION) -eq 3 -a $(PATCHLEVEL) -ge > 4 > \) \) -a \ > + -z "$(ext3_dep_check)" ] ; then \ > + echo "warn" ; \ > + exit ; \ > +fi; \ > +echo "lttng-probe-ext3.o" ; \ > fi; \ > - echo "lttng-probe-ext3.o" ; \ > fi;) > ifeq ($(ext3),warn) > $(warning Files $(ext3_dep) not found. Probe "ext3" is disabled. Use full > kernel > source tree to enable it.) > -- > 2.7.4 -- 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
Re: [lttng-dev] [PATCH lttng-modules] Fix: Add support for 4.9.27-rt18 kernel
On 2017-05-24 11:19, Michael Jeanson wrote: > Signed-off-by: Michael Jeanson> --- > instrumentation/events/lttng-module/sched.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/instrumentation/events/lttng-module/sched.h > b/instrumentation/events/lttng-module/sched.h > index c68dd27..e6f36b1 100644 > --- a/instrumentation/events/lttng-module/sched.h > +++ b/instrumentation/events/lttng-module/sched.h > @@ -540,7 +540,8 @@ LTTNG_TRACEPOINT_EVENT(sched_stat_runtime, > ) > #endif > > -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0)) > +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0) || \ > + LTTNG_RT_KERNEL_RANGE(4,9,27,18, 4,10,0,0)) > /* > * Tracepoint for showing priority inheritance modifying a tasks > * priority. > It applies on top of "Fix: update sched instrumentation for kernel 4.12" Michael ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-modules] Fix: Add support for 4.9.27-rt18 kernel
- On May 24, 2017, at 5:19 PM, Michael Jeanson mjean...@efficios.com wrote: > Signed-off-by: Michael JeansonIt does not appear to apply cleanly to lttng-modules master branch, can you double-check ? Thanks, Mathieu > --- > instrumentation/events/lttng-module/sched.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/instrumentation/events/lttng-module/sched.h > b/instrumentation/events/lttng-module/sched.h > index c68dd27..e6f36b1 100644 > --- a/instrumentation/events/lttng-module/sched.h > +++ b/instrumentation/events/lttng-module/sched.h > @@ -540,7 +540,8 @@ LTTNG_TRACEPOINT_EVENT(sched_stat_runtime, > ) > #endif > > -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0)) > +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,12,0) || \ > + LTTNG_RT_KERNEL_RANGE(4,9,27,18, 4,10,0,0)) > /* > * Tracepoint for showing priority inheritance modifying a tasks > * priority. > -- > 2.7.4 -- 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
Re: [lttng-dev] [PATCH lttng-tools] Fix: thread exit vs futex wait/wakeup race
Merged in master, stable-2.10, stable-2.9, and stable-2.8. Thanks! Jérémie On 17 May 2017 at 18:36, Mathieu Desnoyerswrote: > relayd_live_stop performs, in this order: > > CMM_STORE_SHARED(live_dispatch_thread_exit, 1); [A] > futex_nto1_wake(_conn_queue.futex);[B] > > whereas thread_dispatcher does: > >while (!CMM_LOAD_SHARED(live_dispatch_thread_exit)) { [1] > > [...] > futex_nto1_prepare(_conn_queue.futex);[2] > [...] > futex_nto1_wait(_conn_queue.futex); [3] > > Unfortunately, on the following sequence: > > [1] [A] [B] [2] [3] > > thread_dispatcher will end up hanging. > > We need to move the live_dispatch_thread_exit load between "prepare" and > "wait" to fix this. > > There are similar scenarios with relay_thread_dispatcher, and the > session daemon thread_dispatch_ust_registration, which are also fixed > here. > > Signed-off-by: Mathieu Desnoyers > --- > src/bin/lttng-relayd/live.c | 6 +- > src/bin/lttng-relayd/main.c | 6 +- > src/bin/lttng-sessiond/main.c | 6 +- > 3 files changed, 15 insertions(+), 3 deletions(-) > > diff --git a/src/bin/lttng-relayd/live.c b/src/bin/lttng-relayd/live.c > index 61acafe..f00270b 100644 > --- a/src/bin/lttng-relayd/live.c > +++ b/src/bin/lttng-relayd/live.c > @@ -654,12 +654,16 @@ void *thread_dispatcher(void *data) > > health_code_update(); > > - while (!CMM_LOAD_SHARED(live_dispatch_thread_exit)) { > + for (;;) { > health_code_update(); > > /* Atomically prepare the queue futex */ > futex_nto1_prepare(_conn_queue.futex); > > + if (CMM_LOAD_SHARED(live_dispatch_thread_exit)) { > + break; > + } > + > do { > health_code_update(); > > diff --git a/src/bin/lttng-relayd/main.c b/src/bin/lttng-relayd/main.c > index 2fcc60a..0eb8e28 100644 > --- a/src/bin/lttng-relayd/main.c > +++ b/src/bin/lttng-relayd/main.c > @@ -977,12 +977,16 @@ static void *relay_thread_dispatcher(void *data) > > health_code_update(); > > - while (!CMM_LOAD_SHARED(dispatch_thread_exit)) { > + for (;;) { > health_code_update(); > > /* Atomically prepare the queue futex */ > futex_nto1_prepare(_conn_queue.futex); > > + if (CMM_LOAD_SHARED(dispatch_thread_exit)) { > + break; > + } > + > do { > health_code_update(); > > diff --git a/src/bin/lttng-sessiond/main.c b/src/bin/lttng-sessiond/main.c > index 9b6f70c..e282a9c 100644 > --- a/src/bin/lttng-sessiond/main.c > +++ b/src/bin/lttng-sessiond/main.c > @@ -1934,12 +1934,16 @@ static void *thread_dispatch_ust_registration(void > *data) > > DBG("[thread] Dispatch UST command started"); > > - while (!CMM_LOAD_SHARED(dispatch_thread_exit)) { > + for (;;) { > health_code_update(); > > /* Atomically prepare the queue futex */ > futex_nto1_prepare(_cmd_queue.futex); > > + if (CMM_LOAD_SHARED(dispatch_thread_exit)) { > + break; > + } > + > do { > struct ust_app *app = NULL; > ust_cmd = NULL; > -- > 2.1.4 > -- Jérémie Galarneau 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
Re: [lttng-dev] Patch for lttng tools to build on Mac OSX 10.11.6
On 24 May 2017 at 10:57, Michael Jeansonwrote: > On 2017-05-24 10:52, Jérémie Galarneau wrote: >> On 23 May 2017 at 09:50, Dávid Beck wrote: >>> Hi Jérémie, >>> >>> I guess this is my lack of lttng understanding. >>> >>> I wanted to play around with relayd on Mac by having a Linux box generating >>> the traces and give it a remote relayd for storing the traces locally on my >>> Mac. >>> >>> I was thinking that I don't need a local sessiond on the Mac for this, do I? >> >> Exactly. The relayd is the only daemon that is needed to receive >> traces remotely. >> >>> >>> To answer your question I want to play around with Rust and Lttng on Mac >>> because I have a few ideas of how to generate a few statistical performance >>> metrics from the traces. Since this is a midnight project I have the luxury >>> to do it in a language that I like as opposed to Java (the viewer) or >>> C/Python (Babeltrace). So eventually I want to build an event collector in >>> Rust, and to test the data flow I thought it is good to have the relayd on >>> Mac. >> >> Good to hear. Don't hesitate to share any progress you make, we're >> always interested! >> >> Jérémie >> >>> >>> Thank you, David > > I could make a patch that sets the correct defaults on macOS and other > similar platforms where we only support building the relayd. Thoughts? Good idea! It will certainly be less error-prone. Jérémie > > Michael > ___ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Jérémie Galarneau 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
Re: [lttng-dev] Patch for lttng tools to build on Mac OSX 10.11.6
On 2017-05-24 10:52, Jérémie Galarneau wrote: > On 23 May 2017 at 09:50, Dávid Beckwrote: >> Hi Jérémie, >> >> I guess this is my lack of lttng understanding. >> >> I wanted to play around with relayd on Mac by having a Linux box generating >> the traces and give it a remote relayd for storing the traces locally on my >> Mac. >> >> I was thinking that I don't need a local sessiond on the Mac for this, do I? > > Exactly. The relayd is the only daemon that is needed to receive > traces remotely. > >> >> To answer your question I want to play around with Rust and Lttng on Mac >> because I have a few ideas of how to generate a few statistical performance >> metrics from the traces. Since this is a midnight project I have the luxury >> to do it in a language that I like as opposed to Java (the viewer) or >> C/Python (Babeltrace). So eventually I want to build an event collector in >> Rust, and to test the data flow I thought it is good to have the relayd on >> Mac. > > Good to hear. Don't hesitate to share any progress you make, we're > always interested! > > Jérémie > >> >> Thank you, David I could make a patch that sets the correct defaults on macOS and other similar platforms where we only support building the relayd. Thoughts? Michael ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Patch for lttng tools to build on Mac OSX 10.11.6
On 23 May 2017 at 09:50, Dávid Beckwrote: > Hi Jérémie, > > I guess this is my lack of lttng understanding. > > I wanted to play around with relayd on Mac by having a Linux box generating > the traces and give it a remote relayd for storing the traces locally on my > Mac. > > I was thinking that I don't need a local sessiond on the Mac for this, do I? Exactly. The relayd is the only daemon that is needed to receive traces remotely. > > To answer your question I want to play around with Rust and Lttng on Mac > because I have a few ideas of how to generate a few statistical performance > metrics from the traces. Since this is a midnight project I have the luxury > to do it in a language that I like as opposed to Java (the viewer) or > C/Python (Babeltrace). So eventually I want to build an event collector in > Rust, and to test the data flow I thought it is good to have the relayd on > Mac. Good to hear. Don't hesitate to share any progress you make, we're always interested! Jérémie > > Thank you, David > > > > 2017. máj. 23. du. 2:34 ezt írta ("Jérémie Galarneau" > ): > > Hi David, > > I'm just wondering what is your use-case for building the lttng client > if the session daemon is not built? > We typically also disable building the client (--disable-bin-lttng) > when building the lttng-relayd for macOS. > > Thanks, > Jérémie > > On 21 May 2017 at 11:30, Dávid Beck wrote: >> Hello Lttng Devs, >> >> Please find a patch attached for building lttng tools with these configure >> flags (on Max OSX): >> >> ./configure --without-lttng-ust --disable-man-pages >> --disable-bin-lttng-consumerd --disable-bin-lttng-sessiond >> --disable-bin-lttng-crash --disable-kmod --disable-extras >> >> >> Best, David >> >> >> >> >> ___ >> lttng-dev mailing list >> lttng-dev@lists.lttng.org >> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev >> > > > > -- > Jérémie Galarneau > EfficiOS Inc. > http://www.efficios.com > > -- Jérémie Galarneau 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