Re: [lttng-dev] Patch for lttng tools to build on Mac OSX 10.11.6

2017-05-24 Thread Michael Jeanson
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?

2017-05-24 Thread Francis Deslauriers
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

2017-05-24 Thread Mathieu Desnoyers
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

2017-05-24 Thread Mathieu Desnoyers
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

2017-05-24 Thread Mathieu Desnoyers
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

2017-05-24 Thread Mathieu Desnoyers
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?

2017-05-24 Thread 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

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

2017-05-24 Thread Mathieu Desnoyers
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

2017-05-24 Thread Michael Jeanson
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

2017-05-24 Thread Mathieu Desnoyers
- On May 24, 2017, at 5:19 PM, Michael Jeanson mjean...@efficios.com wrote:

> Signed-off-by: Michael Jeanson 

It 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

2017-05-24 Thread Jérémie Galarneau
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 Desnoyers
 wrote:
> 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

2017-05-24 Thread Jérémie Galarneau
On 24 May 2017 at 10:57, Michael Jeanson  wrote:
> 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

2017-05-24 Thread Michael Jeanson
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?

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

2017-05-24 Thread Jérémie Galarneau
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
>
>
>
> 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