On 11-02-02 03:35 AM, Nils Carlson wrote:
Hi David,
I will try to comment as well as I can below...
David Goulet wrote:
Model
-----------------
A global and/or per-user registry keeps track of all tracing sessions.
Any user
that wants to manage either a kernel trace using LTTng or an
application trace
with UST must interact with that registry for any possible actions.
We can start here... :-)
What do we need the session daemon for in the case where a single user
has downloaded
and compiled UST in his home directory? What is wrong with the socket
per app
and direct connection approach. Please clarify WHAT exactly we need a
session daemon for.
I will.
This daemon is also responsible for tracing buffers creation. Two main
reasons
motivate this design:
* The ltt-sessiond needs to keep track of all the shared memory
segments in
order to be able to give reference to any other possible consumer.
* For the case of sharing tracing buffers between all userspace
applications, having the registry allocating them will allow that but, if
the inprocess library was allocating them, we will need to redesign the
whole model.
Ok, here I once again need a motivation in the text.
App is user A
Session daemon user root with gid trace
consumer has gid trace.
Here is another approach that I'd like you to consider.
app creates buffer with mode 0700.
the session daemon is connected so the app sends a reference to the
session daemon containing the shmid.
The trace daemon changes the mode to 0750 and the gid to the tracing group
and then discards the reference. Hej presto, we don't need to keep a
reference
to the shared memory and the consumers can happily consume.
However, for another consumer that can jump in, who's gonna give him the
shared memory reference? I can't be the inprocess lib because we need to
manage access rights in order to NOT allow anyone reading these buffers.
This is why, the only way to get that reference is either be an
application or being able to talk to sessiond via the socket 660
(root:tracing).
I was mistaken last time when I told you that the apps CANNOT set the
gid tracing. Actually, it's possible to set once credentials on a shm
without having the rights.
The trace roles of ltt-sessiond:
Trace interaction - Create, Destroy, Pause, Stop, Start, Set options
Registry - keep track of trace's information:
* shared memory location (only the keyid)
* application PID (UST)
* type (kernel or UST)
* session name
* UID
Can a non-priviled user trace the kernel?
Eventually, by some voodoo LTTng-Desnoyers tricks, we will be able to do
that for the tracing group.
Also, how aware are multiple session daemons of each other?
Per-user sessiond are not design to be aware of each others. I should
mention that! thanks.
UST-CONSUMERD:
Ok, we can start with a little note. ust-consumerd could just as well
have been
called ust-disk-consumer. It instantiates libustconsumer which does the
work.
I would want you to re-write this chapter taking into account multiple
instances
of libustconsumer.
I can put a use case where multiple ust-consumerd live together.
The purpose of this daemon is to consume the UST trace buffers for only a
specific session. The session MAY have several traces for example two
different
applications. The client tool, drtrace has to create the ust-consumerd
if NONE
is available for that session. It is very important to understand that
for a
tracing session, there is only one ust-consumerd for all the traced
applications.
So we are back at one libustconsumer instance per session? Why do we
want so many
processes hanging about?
Actually, you can argue that the number of process is less.
Ex: One session for one user (UST) means one ust-consumerd per CPU.
ust-consumerd could act as a thread pool for that.
Quick buffer snapshot:
1) Here, drtrace will request a buffer snapshot for an already running
session.
+-----------+ +--------------+ | drtrace A |-------- ops ------->|
ltt-sessiond | +-----------+ +--------------+ | | command
| +-----------------+ +-------+<--+
| | ust-consumerd 1 |<----| app_1 |-+
| +-----------------+ +-------+ | write
| 1 | v | | +-------------+
| +--- read ----->| shared mem. |
| +-------------+ | ^ | +-----------------+ |
+->| ust-consumerd 2 |----------+
+-----------------+ snapshot
| write
|
+---> disk/network
Hm, here you have the session daemon acting as a command router. I
really don't
recommend that.
I do agree about that. Way more complex. But... the only way we could
think of for security.
I think I have to end here... But there is an old adage from somewhere
that goes
"show us the code". This form of programming on paper and design by
committee
is very painful, takes a lot of time and creates a lot of strife.
Oh yes...!
I recommend you put down the pen and start coding away instead. Put some
patches
up and we can review them and try them out. I think that you will
realize that
you want to minimize the amount of state that you replicate as well as
the total
amount of information you keep track of. Once you've done that we can start
discussing models again.
Even if we were to rubber stamp a final Daemon model proposal you can
very well
run into design issues along the way that force you to completely change
your
approach.
Yep! Now is the time to get some codes out! :)
We will incrementally get better, found problems and so on.
Thanks for these precious feedbacks!
David
/Nils
--
David Goulet
LTTng project, DORSAL Lab.
PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A 14C6 4AF7 C14B 16BD 8563
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
