[lttng-dev] [PATCH] Expose kernel tracer to user-space (version 5)

Francis Giraldeau francis.giraldeau at gmail.com
Mon Jul 2 10:52:39 EDT 2012


Le 2012-07-02 16:13, Mathieu Desnoyers a écrit :
> * Francis Giraldeau (francis.giraldeau at gmail.com) wrote:
>> By writing to the file /proc/lttng, a user-space application creates a
>> kernel event. The event's payload is by default UTF-8 text, but any data
>> can be written, up to 1024 bytes. Null-character is optional and is not
>> enforced. The event uses sequence for space efficiency and to store any
>> data as payload.
> 
> Why limit to 1024 bytes ? We could use a string_from_user, and write it
> into a null-terminated string instead.

This is the same limit as printk:

  #define LOG_LINE_MAX 1024

We can't use string_from_user because it's not possible to assume that
the string from user-space is null terminated and we can't changed it in
order to avoid double copy. Thus, I think the current mechanism is
appropriate.

Anyway, if the application really wants all the data to be written, then
it can create another event with the remaining data, since the number of
bytes written is returned.

>> The feature is enabled when both lttng-uevent and lttng-probe-uevent are
>> loaded.
> 
> Why not combine those two into a single module ?

The problem is that the probe code creates it's own module_init and
module_exit functions, and I didn't found a way to override properly and
still call the probe registration. The easy way was to create two
modules, but yes I would prefer it to be combined. What can be done for
that?

>> Module unload must be prevented while lttng-uevent is being used.
>> rcu_synchronized() is call on module unload, and thus rcu_read_lock() can be
> 
> is call -> is called, or is invoked

fixed.

Thanks!

Francis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4489 bytes
Desc: Signature cryptographique S/MIME
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20120702/277bafa9/attachment.bin>


More information about the lttng-dev mailing list