[ltt-dev] [RFC UST and LTTng] Daemon model proposal

[Michel Dagenais]

> 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?