From: david.goulet@polymtl.ca (David Goulet)
Subject: [ltt-dev] [RFC UST and LTTNG] Daemon model proposal v0.3
Date: Mon, 31 Jan 2011 14:16:01 -0500 [thread overview]
Message-ID: <4D470A71.6060805@polymtl.ca> (raw)
In-Reply-To: <20110131190634.GA20150@Krystal>
On 11-01-31 02:06 PM, Mathieu Desnoyers wrote:
> * David Goulet (david.goulet at polymtl.ca) wrote:
>> Everything about a per-user ltt-sessiond will be added to the RFC!
>>
>> Comments below.
>>
>> On 11-01-31 12:10 PM, Mathieu Desnoyers wrote:
>>> * David Goulet (david.goulet at polymtl.ca) wrote:
>>>> This unique identifier SHOULD be a unique string consisting of the username, a
>>>> session name and the number of already created session plus one. The last
>>>> number makes sure that the ID is unique in the ltt-sessiond context. In the
>>>> implementation, a simple number could be use for performance purpose instead of
>>>> comparing string at each iteration.
>>>>
>>>> Ex: Username - "dave", Session name - "mysession", Num. sessions - fifth one
>>>> --> ID: dave.mysession-5
>>>
>>> We will run into problems across reboots: session IDs might be reused, thus
>>> trying to overwrite older traces. Other ideas, possibly including UUID, would be
>>> welcome.
>>
>> Across reboot... I don't see the problem reusing IDs... The only problem
>> to overwrite older traces is if the session ID is used in the trace path
>> on the disk which is not the case.
>
> Then what do you propose using as directory name to hold the trace on disk ?
> Using the session name would seem natural.
Yep, absolutely for the first level directory but the trace file path
should be quite different. We talked about something like this the other
day :
$sessionID/
$appname-$date-$time-$PID
having $sessionID the above proposition : dave.session_name-5
The $time is a bit useless but makes the trace path "unique" since the
case of having the same date, appname and PID can occur.
I'm actually quite open for better suggestion :)
I'll make sure the rest of that email is taking into account for the
next version!
Thanks
David
--
David Goulet
LTTng project, DORSAL Lab.
PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A 14C6 4AF7 C14B 16BD 8563
next prev parent reply other threads:[~2011-01-31 19:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4D433675.3080102@polymtl.ca>
[not found] ` <4D4336BE.7030401@polymtl.ca>
[not found] ` <20110131171012.GA12560@Krystal>
[not found] ` <4D4704A6.4010203@polymtl.ca>
2011-01-31 19:06 ` Mathieu Desnoyers
2011-01-31 19:16 ` David Goulet [this message]
2011-01-31 19:26 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D470A71.6060805@polymtl.ca \
--to=david.goulet@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox