David Goulet dgoulet at efficios.com
Fri Feb 10 10:56:07 EST 2012

Hash: SHA1

On 12-02-10 10:28 AM, Mathieu Desnoyers wrote:
> * Thibault, Daniel (Daniel.Thibault at 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,
> Mathieu
>> Daniel U. Thibault
>> R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D 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
>> 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 at lists.lttng.org
>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Version: GnuPG v1.4.10 (GNU/Linux)


More information about the lttng-dev mailing list