[lttng-dev] how does ust tracer map share lttng buffer

[mathieu.desnoyers@efficios.com (Mathieu Desnoyers)]

----- Original Message -----

> From: "???" <39017736@qq.com>
> To: "mathieu.desnoyers" <mathieu.desnoyers at efficios.com>
> Sent: Friday, November 15, 2013 11:37:11 AM
> Subject: how does ust tracer map share lttng buffer

> Hi,Mathieu

> After lttng sub-command enable-event is issued at first time, lttng-consumerd
> will be informed by lttng-sessiond to open and mmap share memory regions
> .Then lttng-sessiond get all shmfds from lttng-consumerd.But how does ust
> tracer map to these share memory regions?

> AFAIK,lttng-sessiond will call do_consumer_create_channel() ,then
> send_channel_uid_to_ust(). What's confused me is in
> send_channel_uid_to_ust(),lttng-sessiond dup() one shmfd , then
> ust_consumer_send_stream_to_ust() to ust tracer, then close the shmfd and
> loop all shmfds. So all duped fds are the same fd-number (say A)and send to
> ust tracer through
> ust_consumer_send_stream_to_ust()->ustctl_send_stream_to_ust()->ustctl_send_stream()->ustcomm_send_fds_unix_sock()(unix
> socket is $HOME/.lttng/lttng-ust-sock-5).Why does it send the same fds to
> ust tracer?
> At ust tracer side,it calls
> handle_message()->ustcomm_recv_stream_from_sessiond() and mmap every
> received fd to share memory region.However,every received fd is different
> from A.So I must miss something anywhere.How does ust tracer map share lttng
> buffer?

In lttng-sessiond, we send file descriptors for each posix SHM associated to every per-cpu buffer to the application over unix socket. So it's more or less : receive FD from consumer, send FD over unix socket to UST, close FD (we loop on this). Indeed, from a sessiond point of view, this will typically use the same FD number, but it's really associated with a different posix SHM each time. David can probably answer your question in more detail. 

Thanks, 

Mathieu 

> PS:code is from lttng-2.3.0 .

> Thanks
> MuXiu.Cao

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131115/3b598b1c/attachment.html>