Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: Daniel.Thibault@drdc-rddc.gc.ca (Thibault, Daniel)
Subject: [lttng-dev] Questions about JUL (was: Re:  lttng-dev Digest, Vol 67, Issue 48)
Date: Tue, 4 Feb 2014 18:59:02 +0000	[thread overview]
Message-ID: <48CF5AC71E61DB46B70D0F388054EFFD267DE218@VAL-E-02.valcartier.drdc-rddc.gc.ca> (raw)

----------------------------------------------------------------------
Date: Tue, 4 Feb 2014 12:17:36 -0500
From: David Goulet <dgoulet@efficios.com>
To: Jim Dumont <jim.dumont at ericsson.com>
Cc: "lttng-dev at lists.lttng.org" <lttng-dev at lists.lttng.org>

>> 3) add-context: does --jul have the same possible context types as --userspace (i.e. ip, pthread_id, procname, vpid, vtid)?
>
> Nope.

   What are the possible context types then?  Or is it just that you can't apply a filter to a jul event?

>> 4) enable-channel:
>> 4.1) Are the --jul --subbuf-size, --num-subbuf and --read-timer defaults the same as with --userspace?
>
> Nope. JUL uses it's internal channel so basically enable channel does NOT support the jul domain thus not having -j in the help/man.

   So you turn jul events on and off using enable/disable-event --all instead?  This is getting a tad confusing: jul events force you to use only enable/disable-event but kernel syscalls force you to use only enable/disable-channel...

>> 4.4) If yes, won't they all degenerate to the virtual machine's user and process IDs?
>
> Not sure I understand this one?

   A Java application is interpreted and runs in a Java virtual machine (JVM).  The userID and processID of any jul events are thus likely to be those of the JVM process.  I would expect Java apps launched by separate users to launch separate JVM instances, but I would also expect two separate Java apps launched by the same user to share a single JVM (the user's) and, therefore, their process IDs.  This could get fun with multi-threaded Java apps.

> Now after answering all this, I feel like either creating a lttng-jul man page or adding a special section in "lttng.1" for the JUL domain explaining all this. Thoughts?

   We definitely need an additional section in "lttng.1".

Daniel U. Thibault
Protection des syst?mes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
Cyber s?curit? pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
R & D pour la d?fense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Qu?bec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>



             reply	other threads:[~2014-02-04 18:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-04 18:59 Thibault, Daniel [this message]
2014-02-04 19:13 ` David Goulet

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=48CF5AC71E61DB46B70D0F388054EFFD267DE218@VAL-E-02.valcartier.drdc-rddc.gc.ca \
    --to=daniel.thibault@drdc-rddc.gc.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