On 11-01-20 09:36 AM, Michel Dagenais wrote:
This time, the proposal is for both LTTng and UST which get integrated
It looks good, the structure is relatively simple. The documentation would
benefit from some motivation for the choices taken IMHO.
Some questions and remarks follow. Most of these questions dont necessarily
imply that the proposal is not the good solution but rather that explanations
and motivations would be useful to convey to the reader why the proposed
architecture was designed in this way.
----------------
This RFC propose brand new UST and LTTng daemon model. This re-engineering was
mostly driven by the need of better security in terms of access rights, tracing
session, LTTng and UST integration and networking such as streaming and remote
control over different traces and
--> scaling may be another consideration to mention
Will be in the next version of the document.
The ltt-sessiond daemon acts as a trace registry i.e. by keeping reference to
all active session and, by active, it means a session in any state other than
destroyed. Each entity we are keeping track of, here session, will have a
unique identifier or pidunique (ID) assign to it.
--> why do we need/want a unique sessiond? To maintain with a single daemon
the list of available applications to trace? In flight recorder mode, tracing is
active and shared memory regions should be held but no other tracing application
may need to run (drtrace, consumer...); it then looks plausible to have a single
process capable of holding to these shared memory regions (in case the traced
application finishes or crashes) and this process can be used to let a user decide
at a later time to discover and connect to these traced applications.
Will be in the next version of the document.
Buffers creation - creates shared memory for the tracing buffers.
--> Why is buffer creation the responsability of the sessiond? Ressource
accounting, preventing abuses, is easier if the traced application via libust does
the buffer creation!
The main reason was because the application cannot set the shared memory
with the read access to the tracing group. (unless the apps uid is in
the tracing group).
Actually, the resources accounting, abuses and so on are now sessiond
jobs. It will make sure it can allocate the buffers, it will keeps
reference to these buffers for possible multiple consumers, in case the
apps crashes, we still have the control over the buffers for drtrace to
access them.
A clear description will be added to the document.
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.
--> why can't drtrace do it? We seem to have a one to one mapping between
drtrace and consumerd? The user starts and sees drtrace but the spawned consumerd
would be less visible and thus less intuitive. If we kill drtrace, does consumerd
survive? can it be reconnected to?
No actually, 1 consumerd = 1 session. Again, a more detail description
will be added.
This daemon basically empty the tracing buffers when asked for and write that
data to disk for future analysis using LTTv or/and TMF (Tracing Monitoring
Frameworks). Upon creation, that daemon UID/GID is set to the user credentials
and so are the data files on disk.
--> please be very specific, which process spawns (fork/exec) which other, what do you
mean by "that daemon UID/GID is set ti the user credentials" is it as such by
default upon forking or is some combination of setuid... calls required for that?
Will be in the next version of the document.
Thanks!
David
--
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
