[ltt-dev] [PATCH 02/13] get name and fmt from permanent eID
Lai Jiangshan
laijs at cn.fujitsu.com
Thu Jan 22 03:28:01 EST 2009
Mathieu Desnoyers wrote:
> * Lai Jiangshan (laijs at cn.fujitsu.com) wrote:
>> struct marker_entry is permanent, we introduce two APIs for
>> getting name and fmt from eIDs.
>>
>> Signed-off-by: Lai Jiangshan <laijs at cn.fujitsu.com>
>> ---
>> b/kernel/marker.c | 34 ++++++++++++++++++++++++++++++++++
>> include/linux/marker.h | 3 +++
>> 2 files changed, 37 insertions(+)
>> diff --git a/include/linux/marker.h b/include/linux/marker.h
>> index 32387e8..2fe8977 100644
>> --- a/include/linux/marker.h
>> +++ b/include/linux/marker.h
>> @@ -238,6 +238,9 @@ extern int marker_probe_unregister_private_data(marker_probe_func *probe,
>> extern void *marker_get_private_data(const char *channel, const char *name,
>> marker_probe_func *probe, int num);
>>
>> +const char *marker_get_name_form_id(u16 channel_id, u16 event_id);
>> +const char *marker_get_fmt_form_id(u16 channel_id, u16 event_id);
>> +
>> /*
>> * marker_synchronize_unregister must be called between the last marker probe
>> * unregistration and the end of module exit to make sure there is no caller
>> diff --git a/kernel/marker.c b/kernel/marker.c
>> index b11a82a..6a918e2 100644
>> --- a/kernel/marker.c
>> +++ b/kernel/marker.c
>> @@ -997,6 +1010,40 @@ void *marker_get_private_data(const char *channel, const char *name,
>> }
>> EXPORT_SYMBOL_GPL(marker_get_private_data);
>>
>> +static struct marker_entry *get_entry_from_id(u16 channel_id, u16 event_id)
>> +{
>> + struct hlist_head *head;
>> + struct hlist_node *node;
>> + struct marker_entry *e, *found = NULL;
>> + u32 hash = hash_32((channel_id << 16) | event_id, MARKER_HASH_BITS);
>> +
>
> Can we add a define rather that hardcoding 16 in the c file ?
I think hardcode will good for checking by review when we haven't use
ltt_channel_id_t and ltt_event_id_t.
>
>> + mutex_lock(&markers_mutex);
>> + head = id_table + hash;
>> + hlist_for_each_entry(e, node, head, id_list) {
>> + if (e->channel_id == channel_id && e->event_id == event_id) {
>> + found = e;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&markers_mutex);
>> + return found;
>
> Hrm, it would be good to add a comment to this function's header telling
> for what validity period we can safely use the marker_entry * returned
> because it is not protected by any mutex.
>
> The idea is that the function is only called when tracing is active, and
> we insure that the marker_entry is kept there (permanent) until the
> trace ends. We are sure that we stopped using the marker entry before
> trace end if we make sure we wait for all references to the trace to be
> down to zero (that includes any bin-to-ascii trace output module which
> uses this get_entry_from_id()) before we consider the trace unused. Not
> only does that require a comment, but we should carefull check the code
> to make sure refcounting is ok.
>
I think I can't write complex comment. (for my poor English)
>
>> +}
>> +
>> +/* must call when ids/marker_entry are kept alive */
>> +const char *marker_get_name_form_id(u16 channel_id, u16 event_id)
>> +{
>> + struct marker_entry *e = get_entry_from_id(channel_id, event_id);
>> + return e ? e->name : NULL;
>> +}
>> +EXPORT_SYMBOL_GPL(marker_get_name_form_id);
>> +
> Same here.
>
>> +const char *marker_get_fmt_form_id(u16 channel_id, u16 event_id)
>> +{
>> + struct marker_entry *e = get_entry_from_id(channel_id, event_id);
>> + return e ? e->format : NULL;
>> +}
>> +EXPORT_SYMBOL_GPL(marker_get_fmt_form_id);
>> +
>
> And here.
>
> Hrm, actually, it might be good to expose the symbol :
>
> get_entry_from_id
It's not a good idea. struct marker_entry is private struct.
>
> So we need only one hash table lookup to use both the name and fmt ?
>
> Mathieu
>
>> /**
>> * markers_compact_event_ids: Compact markers event IDs and reassign channels
>> *
>>
>>
>>
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>
>
More information about the lttng-dev
mailing list