> 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
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.
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 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?
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?
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
