-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12-02-10 10:28 AM, Mathieu Desnoyers wrote:
* Thibault, Daniel (daniel.thiba...@drdc-rddc.gc.ca) wrote:
I would like to suggest adding to lttng.h an lttng_domain_type enum value
of LTTNG_DOMAIN_UNSPECIFIED = 0.
enum lttng_domain_type {
+LTTNG_DOMAIN_UNSPECIFIED = 0,
LTTNG_DOMAIN_KERNEL = 1,
This would simplify handling of domain option switches
(-k/--kernel, -u/--userspace) in the various commands (add_context,
calibrate, etc.). Instead of a chain of if-else-if checking the
command-line options (currently opt_kernel, opt_userspace) one at a
time, we could have the command-line interpreter set an opt_domain
variable (initially LTTNG_DOMAIN_UNSPECIFIED) as each domain switch
is encountered (allowing for easily recognising a multiple-context
situation as a (opt_domain != LTTNG_DOMAIN_UNSPECIFIED) test), and
later processing could use a switch instead of the aforementioned
if-then-else-if chain. It would make adding the currently planned
additional domains easier.
I think it would be a good idea, in general, to keep the 0 values of
enumerations as unspecified (or default) behavior, since as we extend
the API structures, those being zero-padded, they will just have a
semantic of default behavior with the zero value.
Yes I agree, it's good idea to have the 0 being the default value. Before that,
please read below.
For the API items currently in place in lttng.h, I don't think it is
worth it changing them at this point of the development. But given there
is nothing assigned to the 0 value of enum lttng_domain_type, I think
it's a good opportunity to do it.
David, can you look into this ?
The zero value was removed for a reason some time ago. I can recall that there
was a good reason to that but I can't find the message since the commit message
was really bad on that change (my bad...).
(commit: 0d0c377ae0d483b1070409811ff5409ab05aa72b).
For, now, I don't think it's a good idea to change it back and I see no reason
for doing so. I'll rather see the domain type handled in the command line tool
and not add an extra value to the API that we'll only be used on the client
side.
Now, to put back the 0 in, we'll have to review *carefully* the code path where
those values are used because I remember that it was triggering something
undesired (maybe removed at this time..). I don't see that for now as a bug fix
so we'll keep that for the 2.1+ version.
I do agree that a chain of if...else is not the optimal but considering we'll
add more domain in later version, a check is necessary to ensure that -k and -u
for example are not used together and the user is informed.
FYI, Daniel, we have now deployed a Redmine at bugs.lttng.org for any bug report
and feature request. I think the feature request ticket should be broadcast to
lttng-dev@ in the future.
Thanks
David
Thanks,
Mathieu
Daniel U. Thibault
R D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence RD
Canada - Valcartier (DRDC Valcartier)
Système de systèmes (SdS) / System of Systems (SoS)
Solutions informatiques et expérimentations (SIE) / Computing Solutions and
Experimentations (CSE)
2459 Boul. Pie XI Nord
Québec, QC G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC: 918V QSDJ
Gouvernement du Canada / Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJPNT4XAAoJEELoaioR9I02vWIH/0A+O781zwnExz2TwO38Ru8n
pDMRIbGZrnZIaAxeZ3MM4dOjhzMb78lFd78NP79MxzdlLF2AeKURGCaD5E12WyYi
r7E6pevAEqMCwISOoUsBFz7xKa795PFhgep66kEgk1baylI8wH4PmOOTLO7bl4cr
SqPvZwpOzkCM9GxswcrLsi80uoFTDvawmCIiJ7og6bD4tMnI/t/w/qVWbW1U38NN
Rf+UdKIqpFuFDJoDMnFdCBq4/fTWgwhjbO/aZyyTvu4MAhtvWSq9Zcf0qz1PHRSP
v1mdOi8RqbdVKs2MQKvJDNpl0fi+mXRKTgO41Ps5CoPW2KmOcOi6kZDJWggapPM=
=y6Rv
-END PGP SIGNATURE-
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
