[ltt-dev] Updated TODO list before releasing LTTng buffering to LKML

[ltt-dev] Updated TODO list before releasing LTTng buffering to LKML

[Mathieu Desnoyers]

Hi everyone,

Thanks for the steady work those past weeks. We are close to a
releasable result. I have been delighted to see people from Fujitsu
helping on various items in the past weeks. Thanks to all those who
report issues and/or provide patches.

Here is an updated Todo list before posting LTTng-buffering to LKML

Timestamping :

- Use kernel/time/tsc-sync.c in MIPS to detect unsync TSCs.
- Tweak kernel/time/tsc-sync.c so it supports sync detection between two
  CPUs so it can be used to replace arch/x86/kernel/tsc_sync.c
- I plan to leave the current cache-line bouncing time source for CPUs
  which have unsynched TSC, but to printk a warning telling the user to
  disabled freq. scaling and halt in idle to make sure the clocks are
  synchronized if he expects precise timestamping and good scalability
  to large number of nodes. Let's keep room for improvement on this
  aspect for later.


Markers :

- Tie the markers to event IDs and buffer name. That will permit to
  simplify a lot of stuff currently in ltt-marker-control.ko. It will
  also remove the need for a global event ID assignation, making it
  per-buffer (in LTTng terminology : per-channel).
  (will be done by myself soon)

- move ltt/ltt-marker-control.c /proc interface to debugfs
  I think we should integrate its directory tree to the new LTTng tracer
  debugfs API like this :

  /debugfs/ltt/events/buffer_name/marker_name/
    where we find files like :
    state
      write : 1/0 (on/off)
      read  : 1/0 (on/off)
    format
      read : marker format string

  (being done by Fujistsu)


LTTng tracer :

- Rip apart ltt/ltt-core.c and put it in ltt/ltt-tracer.c. This
  "builtin" part of LTTng can now sit in a module without any problem.
  This can be done because we have the markers to abstract all
  interactions with the tracer.
  (will be done by myself soon)

- switch ltt-control.ko (currently over netlink) to debugfs
  (being done by Fujistsu)

- Create a ltt-ascii.ko kernel module which merge-sorts the buffers and exports
  them to userspace through a debugfs file.
  (will be done by Fujistu)

- merge a simplified lttv in lttng
  (will be done by myself)

As always, feel free to indicate if you are willing to help on any of
these items. If you need some pointers to the current state of work for
a particular item, just ask and I'll give you the pointer to the patch
within the -lttng git tree.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[ltt-dev] Updated TODO list before releasing LTTng buffering to LKML

[Zhaolei]

> Hi everyone,
> 
> Thanks for the steady work those past weeks. We are close to a
> releasable result. I have been delighted to see people from Fujitsu
> helping on various items in the past weeks. Thanks to all those who
> report issues and/or provide patches.
> 
> Here is an updated Todo list before posting LTTng-buffering to LKML
> 
> Timestamping :
> 
> - Use kernel/time/tsc-sync.c in MIPS to detect unsync TSCs.
> - Tweak kernel/time/tsc-sync.c so it supports sync detection between two
>  CPUs so it can be used to replace arch/x86/kernel/tsc_sync.c
> - I plan to leave the current cache-line bouncing time source for CPUs
>  which have unsynched TSC, but to printk a warning telling the user to
>  disabled freq. scaling and halt in idle to make sure the clocks are
>  synchronized if he expects precise timestamping and good scalability
>  to large number of nodes. Let's keep room for improvement on this
>  aspect for later.
> 
> 
> Markers :
> 
> - Tie the markers to event IDs and buffer name. That will permit to
>  simplify a lot of stuff currently in ltt-marker-control.ko. It will
>  also remove the need for a global event ID assignation, making it
>  per-buffer (in LTTng terminology : per-channel).
>  (will be done by myself soon)
> 
> - move ltt/ltt-marker-control.c /proc interface to debugfs
>  I think we should integrate its directory tree to the new LTTng tracer
>  debugfs API like this :
> 
>  /debugfs/ltt/events/buffer_name/marker_name/
>    where we find files like :
>    state
>      write : 1/0 (on/off)
>      read  : 1/0 (on/off)
>    format
>      read : marker format string
Hello, Mathieu,

So we need to create a marker's debugfs-directory when user insmod
 a module with markers.
But i think we don't have a callback when user insmod, and we
 should avoid to patch kernel/module.c for this kind of function.

So, maybe we can only "echo marker_name 0/1" > marker-control.
Dou you have suggestion for me?

> 
>  (being done by Fujistsu)
> 
> 
> LTTng tracer :
> 
> - Rip apart ltt/ltt-core.c and put it in ltt/ltt-tracer.c. This
>  "builtin" part of LTTng can now sit in a module without any problem.
>  This can be done because we have the markers to abstract all
>  interactions with the tracer.
>  (will be done by myself soon)
> 
> - switch ltt-control.ko (currently over netlink) to debugfs
>  (being done by Fujistsu)
> 
> - Create a ltt-ascii.ko kernel module which merge-sorts the buffers and exports
>  them to userspace through a debugfs file.
>  (will be done by Fujistu)
> 
> - merge a simplified lttv in lttng
>  (will be done by myself)
> 
> As always, feel free to indicate if you are willing to help on any of
> these items. If you need some pointers to the current state of work for
> a particular item, just ask and I'll give you the pointer to the patch
> within the -lttng git tree.
> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> 
>

[ltt-dev] Updated TODO list before releasing LTTng buffering to LKML

[Mathieu Desnoyers]

* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> 
> > Hi everyone,
> > 
> > Thanks for the steady work those past weeks. We are close to a
> > releasable result. I have been delighted to see people from Fujitsu
> > helping on various items in the past weeks. Thanks to all those who
> > report issues and/or provide patches.
> > 
> > Here is an updated Todo list before posting LTTng-buffering to LKML
> > 
> > Timestamping :
> > 
> > - Use kernel/time/tsc-sync.c in MIPS to detect unsync TSCs.
> > - Tweak kernel/time/tsc-sync.c so it supports sync detection between two
> >  CPUs so it can be used to replace arch/x86/kernel/tsc_sync.c
> > - I plan to leave the current cache-line bouncing time source for CPUs
> >  which have unsynched TSC, but to printk a warning telling the user to
> >  disabled freq. scaling and halt in idle to make sure the clocks are
> >  synchronized if he expects precise timestamping and good scalability
> >  to large number of nodes. Let's keep room for improvement on this
> >  aspect for later.
> > 
> > 
> > Markers :
> > 
> > - Tie the markers to event IDs and buffer name. That will permit to
> >  simplify a lot of stuff currently in ltt-marker-control.ko. It will
> >  also remove the need for a global event ID assignation, making it
> >  per-buffer (in LTTng terminology : per-channel).
> >  (will be done by myself soon)
> > 
> > - move ltt/ltt-marker-control.c /proc interface to debugfs
> >  I think we should integrate its directory tree to the new LTTng tracer
> >  debugfs API like this :
> > 
> >  /debugfs/ltt/events/buffer_name/marker_name/
> >    where we find files like :
> >    state
> >      write : 1/0 (on/off)
> >      read  : 1/0 (on/off)
> >    format
> >      read : marker format string
> Hello, Mathieu,
> 
> So we need to create a marker's debugfs-directory when user insmod
>  a module with markers.
> But i think we don't have a callback when user insmod, and we
>  should avoid to patch kernel/module.c for this kind of function.
> 
> So, maybe we can only "echo marker_name 0/1" > marker-control.
> Dou you have suggestion for me?
> 


Yes, we do have a callback in insmod.

See :

load_module()

#ifdef CONFIG_MARKERS
        if (!mod->taints)
                marker_update_probe_range(mod->markers,
                        mod->markers + mod->num_markers);
#endif

We would probably also have to get a callback in free_module to remove
the marker directory entry when the last marker reference is gone. The
same

#ifdef CONFIG_MARKERS
        if (!mod->taints)
                marker_update_probe_range(mod->markers,
                        mod->markers + mod->num_markers);
#endif

Could probably be used in free_module.

One of the main difference in the marker.c code will be that we would
have to keep a marker entry (in the hash table) for every marker present
in the kernel core or in modules. It will contain the reference count,
incremented each time a marker struct is encountered in the core kernel
or in loaded modules, and decremented at each time is is encountered at
module unload.

I know this kind of directory structure is a bit more elaborated than
what is currently present in LTTng and also more complex to implement,
but there seemed to be a strong agreement amongst people present at the
tracing meeting at the Linux Plumber Conference that this kind of API is
expected and indeed very simple to understand and use.

Mathieu

> > 
> >  (being done by Fujistsu)
> > 
> > 
> > LTTng tracer :
> > 
> > - Rip apart ltt/ltt-core.c and put it in ltt/ltt-tracer.c. This
> >  "builtin" part of LTTng can now sit in a module without any problem.
> >  This can be done because we have the markers to abstract all
> >  interactions with the tracer.
> >  (will be done by myself soon)
> > 
> > - switch ltt-control.ko (currently over netlink) to debugfs
> >  (being done by Fujistsu)
> > 
> > - Create a ltt-ascii.ko kernel module which merge-sorts the buffers and exports
> >  them to userspace through a debugfs file.
> >  (will be done by Fujistu)
> > 
> > - merge a simplified lttv in lttng
> >  (will be done by myself)
> > 
> > As always, feel free to indicate if you are willing to help on any of
> > these items. If you need some pointers to the current state of work for
> > a particular item, just ask and I'll give you the pointer to the patch
> > within the -lttng git tree.
> > 
> > Thanks,
> > 
> > Mathieu
> > 
> > -- 
> > Mathieu Desnoyers
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> > 
> >
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[ltt-dev] Updated TODO list before releasing LTTng bufferingto LKML

[Zhaolei]

* Mathieu Desnoyers wrote:
>> > - move ltt/ltt-marker-control.c /proc interface to debugfs
>> >  I think we should integrate its directory tree to the new LTTng tracer
>> >  debugfs API like this :
>> > 
>> >  /debugfs/ltt/events/buffer_name/marker_name/
>> >    where we find files like :
>> >    state
>> >      write : 1/0 (on/off)
>> >      read  : 1/0 (on/off)
>> >    format
>> >      read : marker format string
>> Hello, Mathieu,
>> 
>> So we need to create a marker's debugfs-directory when user insmod
>>  a module with markers.
>> But i think we don't have a callback when user insmod, and we
>>  should avoid to patch kernel/module.c for this kind of function.
>> 
>> So, maybe we can only "echo marker_name 0/1" > marker-control.
>> Dou you have suggestion for me?
>> 
> 
> 
> Yes, we do have a callback in insmod.
> 
> See :
> 
> load_module()
> 
> #ifdef CONFIG_MARKERS
>        if (!mod->taints)
>                marker_update_probe_range(mod->markers,
>                        mod->markers + mod->num_markers);
> #endif
> 
> We would probably also have to get a callback in free_module to remove
> the marker directory entry when the last marker reference is gone. The
> same
> 
> #ifdef CONFIG_MARKERS
>        if (!mod->taints)
>                marker_update_probe_range(mod->markers,
>                        mod->markers + mod->num_markers);
> #endif
> 
> Could probably be used in free_module.
> 
Do you means we insert another callback as markers do?
as example in insmod:
#ifdef CONFIG_MARKERS
    if (!mod->taints)
        marker_update_probe_range(mod->markers,
         mod->markers + mod->num_markers);
#endif
#ifdef CONFIG_LTT
    if (!mod->taints)
        lttctl_create_dirs(mod->markers,
        mod->markers + mod->num_markers);
#endif

It it is true, i think because ltt_control will be a kernel module, and we can't
call a module's function in load_module().

So, maybe we can do as following:
1: make module.c support callbackset.
  add following functions to module.c
  module_register_callback(enum MODULE_CALLBACK_TYPE type, callback_func func);
  module_unregister_callback(LOAD_MODULE, callback_func func);

2: make marks and ltt_control use new function
  example if ltt_control's
  init() {module_register_callback(LOAD_MODULE, create_debugfs_dir);}
  exit() {module_unregister_callback(LOAD_MODULE, free_debugfs_dir);}
  void create_debugfs_dir(struct module *mod) {
    for (i = 0; i < mod->num_markers; i++ )
        ...
    }

[ltt-dev] Updated TODO list before releasing LTTng bufferingtoLKML

[Zhaolei]

* Zhaolei wrote:
>* Mathieu Desnoyers wrote:
>>> > - move ltt/ltt-marker-control.c /proc interface to debugfs
>>> >  I think we should integrate its directory tree to the new LTTng tracer
>>> >  debugfs API like this :
>>> > 
>>> >  /debugfs/ltt/events/buffer_name/marker_name/
>>> >    where we find files like :
>>> >    state
>>> >      write : 1/0 (on/off)
>>> >      read  : 1/0 (on/off)
>>> >    format
>>> >      read : marker format string
>>> Hello, Mathieu,
>>> 
>>> So we need to create a marker's debugfs-directory when user insmod
>>>  a module with markers.
>>> But i think we don't have a callback when user insmod, and we
>>>  should avoid to patch kernel/module.c for this kind of function.
>>> 
>>> So, maybe we can only "echo marker_name 0/1" > marker-control.
>>> Dou you have suggestion for me?
>>> 
>> 
>> 
>> Yes, we do have a callback in insmod.
>> 
>> See :
>> 
>> load_module()
>> 
>> #ifdef CONFIG_MARKERS
>>        if (!mod->taints)
>>                marker_update_probe_range(mod->markers,
>>                        mod->markers + mod->num_markers);
>> #endif
>> 
>> We would probably also have to get a callback in free_module to remove
>> the marker directory entry when the last marker reference is gone. The
>> same
>> 
>> #ifdef CONFIG_MARKERS
>>        if (!mod->taints)
>>                marker_update_probe_range(mod->markers,
>>                        mod->markers + mod->num_markers);
>> #endif
>> 
>> Could probably be used in free_module.
>> 
> Do you means we insert another callback as markers do?
> as example in insmod:
> #ifdef CONFIG_MARKERS
>    if (!mod->taints)
>        marker_update_probe_range(mod->markers,
>         mod->markers + mod->num_markers);
> #endif
> #ifdef CONFIG_LTT
>    if (!mod->taints)
>        lttctl_create_dirs(mod->markers,
>        mod->markers + mod->num_markers);
> #endif
> 
> It it is true, i think because ltt_control will be a kernel module, and we can't
> call a module's function in load_module().
> 
> So, maybe we can do as following:
> 1: make module.c support callbackset.
>  add following functions to module.c
>  module_register_callback(enum MODULE_CALLBACK_TYPE type, callback_func func);
>  module_unregister_callback(LOAD_MODULE, callback_func func);
Sorry for my mistake
module_unregister_callback(LOAD_MODULE, callback_func func);
-> module_unregister_callback(enum MODULE_CALLBACK_TYPE type, callback_func func);

> 
> 2: make marks and ltt_control use new function
>  example if ltt_control's
>  init() {module_register_callback(LOAD_MODULE, create_debugfs_dir);}
>  exit() {module_unregister_callback(LOAD_MODULE, free_debugfs_dir);}
>  void create_debugfs_dir(struct module *mod) {
>    for (i = 0; i < mod->num_markers; i++ )
>        ...
>    }
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 
>

[ltt-dev] Updated TODO list before releasing LTTng bufferingto LKML

[Mathieu Desnoyers]

* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> * Mathieu Desnoyers wrote:
> >> > - move ltt/ltt-marker-control.c /proc interface to debugfs
> >> >  I think we should integrate its directory tree to the new LTTng tracer
> >> >  debugfs API like this :
> >> > 
> >> >  /debugfs/ltt/events/buffer_name/marker_name/
> >> >    where we find files like :
> >> >    state
> >> >      write : 1/0 (on/off)
> >> >      read  : 1/0 (on/off)
> >> >    format
> >> >      read : marker format string
> >> Hello, Mathieu,
> >> 
> >> So we need to create a marker's debugfs-directory when user insmod
> >>  a module with markers.
> >> But i think we don't have a callback when user insmod, and we
> >>  should avoid to patch kernel/module.c for this kind of function.
> >> 
> >> So, maybe we can only "echo marker_name 0/1" > marker-control.
> >> Dou you have suggestion for me?
> >> 
> > 
> > 
> > Yes, we do have a callback in insmod.
> > 
> > See :
> > 
> > load_module()
> > 
> > #ifdef CONFIG_MARKERS
> >        if (!mod->taints)
> >                marker_update_probe_range(mod->markers,
> >                        mod->markers + mod->num_markers);
> > #endif
> > 
> > We would probably also have to get a callback in free_module to remove
> > the marker directory entry when the last marker reference is gone. The
> > same
> > 
> > #ifdef CONFIG_MARKERS
> >        if (!mod->taints)
> >                marker_update_probe_range(mod->markers,
> >                        mod->markers + mod->num_markers);
> > #endif
> > 
> > Could probably be used in free_module.
> > 
> Do you means we insert another callback as markers do?
> as example in insmod:
> #ifdef CONFIG_MARKERS
>     if (!mod->taints)
>         marker_update_probe_range(mod->markers,
>          mod->markers + mod->num_markers);
> #endif
> #ifdef CONFIG_LTT
>     if (!mod->taints)
>         lttctl_create_dirs(mod->markers,
>         mod->markers + mod->num_markers);
> #endif
> 
> It it is true, i think because ltt_control will be a kernel module, and we can't
> call a module's function in load_module().
> 
> So, maybe we can do as following:
> 1: make module.c support callbackset.
>   add following functions to module.c
>   module_register_callback(enum MODULE_CALLBACK_TYPE type, callback_func func);
>   module_unregister_callback(LOAD_MODULE, callback_func func);
> 
> 2: make marks and ltt_control use new function
>   example if ltt_control's
>   init() {module_register_callback(LOAD_MODULE, create_debugfs_dir);}
>   exit() {module_unregister_callback(LOAD_MODULE, free_debugfs_dir);}
>   void create_debugfs_dir(struct module *mod) {
>     for (i = 0; i < mod->num_markers; i++ )
>         ...
>     }
> 

No, no...

only marker_update_probe_range() needs to be called form module.c, at
load_module() and exit_module().

It will add a marker entry to the hash table when necessary, and
increment/decrement the reference count of this marker entry. The marker
entry can be removed from the hash table when the refcount falls to 0
and no probe is registered on the marker.

At the same time the marker entry is added to the hash table, a
debugfs mkdir is done. When the entry is removed from the hash table, a
debugfs rmdir is done.

Is it a bit more clear ?

Mathieu




> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[ltt-dev] Updated TODO list before releasing LTTng bufferingtoLKML

[Zhaolei]

* Mathieu Desnoyers wrote:
>* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>> * Mathieu Desnoyers wrote:
>> >> > - move ltt/ltt-marker-control.c /proc interface to debugfs
>> >> >  I think we should integrate its directory tree to the new LTTng tracer
>> >> >  debugfs API like this :
>> >> > 
>> >> >  /debugfs/ltt/events/buffer_name/marker_name/
>> >> >    where we find files like :
>> >> >    state
>> >> >      write : 1/0 (on/off)
>> >> >      read  : 1/0 (on/off)
>> >> >    format
>> >> >      read : marker format string
>> >> Hello, Mathieu,
>> >> 
>> >> So we need to create a marker's debugfs-directory when user insmod
>> >>  a module with markers.
>> >> But i think we don't have a callback when user insmod, and we
>> >>  should avoid to patch kernel/module.c for this kind of function.
>> >> 
>> >> So, maybe we can only "echo marker_name 0/1" > marker-control.
>> >> Dou you have suggestion for me?
>> >> 
>> > 
>> > 
>> > Yes, we do have a callback in insmod.
>> > 
>> > See :
>> > 
>> > load_module()
>> > 
>> > #ifdef CONFIG_MARKERS
>> >        if (!mod->taints)
>> >                marker_update_probe_range(mod->markers,
>> >                        mod->markers + mod->num_markers);
>> > #endif
>> > 
>> > We would probably also have to get a callback in free_module to remove
>> > the marker directory entry when the last marker reference is gone. The
>> > same
>> > 
>> > #ifdef CONFIG_MARKERS
>> >        if (!mod->taints)
>> >                marker_update_probe_range(mod->markers,
>> >                        mod->markers + mod->num_markers);
>> > #endif
>> > 
>> > Could probably be used in free_module.
>> > 
>> Do you means we insert another callback as markers do?
>> as example in insmod:
>> #ifdef CONFIG_MARKERS
>>     if (!mod->taints)
>>         marker_update_probe_range(mod->markers,
>>          mod->markers + mod->num_markers);
>> #endif
>> #ifdef CONFIG_LTT
>>     if (!mod->taints)
>>         lttctl_create_dirs(mod->markers,
>>         mod->markers + mod->num_markers);
>> #endif
>> 
>> It it is true, i think because ltt_control will be a kernel module, and we can't
>> call a module's function in load_module().
>> 
>> So, maybe we can do as following:
>> 1: make module.c support callbackset.
>>   add following functions to module.c
>>   module_register_callback(enum MODULE_CALLBACK_TYPE type, callback_func func);
>>   module_unregister_callback(LOAD_MODULE, callback_func func);
>> 
>> 2: make marks and ltt_control use new function
>>   example if ltt_control's
>>   init() {module_register_callback(LOAD_MODULE, create_debugfs_dir);}
>>   exit() {module_unregister_callback(LOAD_MODULE, free_debugfs_dir);}
>>   void create_debugfs_dir(struct module *mod) {
>>     for (i = 0; i < mod->num_markers; i++ )
>>         ...
>>     }
>> 
> 
> No, no...
> 
> only marker_update_probe_range() needs to be called form module.c, at
> load_module() and exit_module().
> 
> It will add a marker entry to the hash table when necessary, and
> increment/decrement the reference count of this marker entry. The marker
> entry can be removed from the hash table when the refcount falls to 0
> and no probe is registered on the marker.
> 
> At the same time the marker entry is added to the hash table, a
> debugfs mkdir is done. When the entry is removed from the hash table, a
> debugfs rmdir is done.
> 
> Is it a bit more clear ?
Hi, Mathieu

I see.
But IMHO, markers is used by lttng, but is not part of lttng.
So, i think source for create files in /debugfs/ltt/... should not be placed in
markers.c.

> 
> Mathieu
> 
> 
> 
> 
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>> 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> 
>

[ltt-dev] Updated TODO list before releasing LTTng bufferingtoLKML

[Mathieu Desnoyers]

* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> * Mathieu Desnoyers wrote:
> >* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> >> * Mathieu Desnoyers wrote:
> >> >> > - move ltt/ltt-marker-control.c /proc interface to debugfs
> >> >> >  I think we should integrate its directory tree to the new LTTng tracer
> >> >> >  debugfs API like this :
> >> >> > 
> >> >> >  /debugfs/ltt/events/buffer_name/marker_name/
> >> >> >    where we find files like :
> >> >> >    state
> >> >> >      write : 1/0 (on/off)
> >> >> >      read  : 1/0 (on/off)
> >> >> >    format
> >> >> >      read : marker format string
> >> >> Hello, Mathieu,
> >> >> 
> >> >> So we need to create a marker's debugfs-directory when user insmod
> >> >>  a module with markers.
> >> >> But i think we don't have a callback when user insmod, and we
> >> >>  should avoid to patch kernel/module.c for this kind of function.
> >> >> 
> >> >> So, maybe we can only "echo marker_name 0/1" > marker-control.
> >> >> Dou you have suggestion for me?
> >> >> 
> >> > 
> >> > 
> >> > Yes, we do have a callback in insmod.
> >> > 
> >> > See :
> >> > 
> >> > load_module()
> >> > 
> >> > #ifdef CONFIG_MARKERS
> >> >        if (!mod->taints)
> >> >                marker_update_probe_range(mod->markers,
> >> >                        mod->markers + mod->num_markers);
> >> > #endif
> >> > 
> >> > We would probably also have to get a callback in free_module to remove
> >> > the marker directory entry when the last marker reference is gone. The
> >> > same
> >> > 
> >> > #ifdef CONFIG_MARKERS
> >> >        if (!mod->taints)
> >> >                marker_update_probe_range(mod->markers,
> >> >                        mod->markers + mod->num_markers);
> >> > #endif
> >> > 
> >> > Could probably be used in free_module.
> >> > 
> >> Do you means we insert another callback as markers do?
> >> as example in insmod:
> >> #ifdef CONFIG_MARKERS
> >>     if (!mod->taints)
> >>         marker_update_probe_range(mod->markers,
> >>          mod->markers + mod->num_markers);
> >> #endif
> >> #ifdef CONFIG_LTT
> >>     if (!mod->taints)
> >>         lttctl_create_dirs(mod->markers,
> >>         mod->markers + mod->num_markers);
> >> #endif
> >> 
> >> It it is true, i think because ltt_control will be a kernel module, and we can't
> >> call a module's function in load_module().
> >> 
> >> So, maybe we can do as following:
> >> 1: make module.c support callbackset.
> >>   add following functions to module.c
> >>   module_register_callback(enum MODULE_CALLBACK_TYPE type, callback_func func);
> >>   module_unregister_callback(LOAD_MODULE, callback_func func);
> >> 
> >> 2: make marks and ltt_control use new function
> >>   example if ltt_control's
> >>   init() {module_register_callback(LOAD_MODULE, create_debugfs_dir);}
> >>   exit() {module_unregister_callback(LOAD_MODULE, free_debugfs_dir);}
> >>   void create_debugfs_dir(struct module *mod) {
> >>     for (i = 0; i < mod->num_markers; i++ )
> >>         ...
> >>     }
> >> 
> > 
> > No, no...
> > 
> > only marker_update_probe_range() needs to be called form module.c, at
> > load_module() and exit_module().
> > 
> > It will add a marker entry to the hash table when necessary, and
> > increment/decrement the reference count of this marker entry. The marker
> > entry can be removed from the hash table when the refcount falls to 0
> > and no probe is registered on the marker.
> > 
> > At the same time the marker entry is added to the hash table, a
> > debugfs mkdir is done. When the entry is removed from the hash table, a
> > debugfs rmdir is done.
> > 
> > Is it a bit more clear ?
> Hi, Mathieu
> 
> I see.
> But IMHO, markers is used by lttng, but is not part of lttng.
> So, i think source for create files in /debugfs/ltt/... should not be placed in
> markers.c.
> 

Let's put LTTng in /debugfs/trace/ then, along with markers. I think the
LTTng name will eventually fade away as bits and pieces gets renamed as
they are merged into mainline. :)

Mathieu


> > 
> > Mathieu
> > 
> > 
> > 
> > 
> >> _______________________________________________
> >> ltt-dev mailing list
> >> ltt-dev at lists.casi.polymtl.ca
> >> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> >> 
> > 
> > -- 
> > Mathieu Desnoyers
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> > 
> >
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[ltt-dev] Updated TODO list before releasing LTTngbufferingtoLKML

[Zhaolei]

* Mathieu Desnoyers wrote:
>* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>> * Mathieu Desnoyers wrote:
>> >* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>> >> * Mathieu Desnoyers wrote:
>> >> >> > - move ltt/ltt-marker-control.c /proc interface to debugfs
>> >> >> >  I think we should integrate its directory tree to the new LTTng tracer
>> >> >> >  debugfs API like this :
>> >> >> > 
>> >> >> >  /debugfs/ltt/events/buffer_name/marker_name/
>> >> >> >    where we find files like :
>> >> >> >    state
>> >> >> >      write : 1/0 (on/off)
>> >> >> >      read  : 1/0 (on/off)
>> >> >> >    format
>> >> >> >      read : marker format string
>> >> >> Hello, Mathieu,
>> >> >> 
>> >> >> So we need to create a marker's debugfs-directory when user insmod
>> >> >>  a module with markers.
>> >> >> But i think we don't have a callback when user insmod, and we
>> >> >>  should avoid to patch kernel/module.c for this kind of function.
>> >> >> 
>> >> >> So, maybe we can only "echo marker_name 0/1" > marker-control.
>> >> >> Dou you have suggestion for me?
>> >> >> 
>> >> > 
>> >> > 
>> >> > Yes, we do have a callback in insmod.
>> >> > 
>> >> > See :
>> >> > 
>> >> > load_module()
>> >> > 
>> >> > #ifdef CONFIG_MARKERS
>> >> >        if (!mod->taints)
>> >> >                marker_update_probe_range(mod->markers,
>> >> >                        mod->markers + mod->num_markers);
>> >> > #endif
>> >> > 
>> >> > We would probably also have to get a callback in free_module to remove
>> >> > the marker directory entry when the last marker reference is gone. The
>> >> > same
>> >> > 
>> >> > #ifdef CONFIG_MARKERS
>> >> >        if (!mod->taints)
>> >> >                marker_update_probe_range(mod->markers,
>> >> >                        mod->markers + mod->num_markers);
>> >> > #endif
>> >> > 
>> >> > Could probably be used in free_module.
>> >> > 
>> >> Do you means we insert another callback as markers do?
>> >> as example in insmod:
>> >> #ifdef CONFIG_MARKERS
>> >>     if (!mod->taints)
>> >>         marker_update_probe_range(mod->markers,
>> >>          mod->markers + mod->num_markers);
>> >> #endif
>> >> #ifdef CONFIG_LTT
>> >>     if (!mod->taints)
>> >>         lttctl_create_dirs(mod->markers,
>> >>         mod->markers + mod->num_markers);
>> >> #endif
>> >> 
>> >> It it is true, i think because ltt_control will be a kernel module, and we can't
>> >> call a module's function in load_module().
>> >> 
>> >> So, maybe we can do as following:
>> >> 1: make module.c support callbackset.
>> >>   add following functions to module.c
>> >>   module_register_callback(enum MODULE_CALLBACK_TYPE type, callback_func func);
>> >>   module_unregister_callback(LOAD_MODULE, callback_func func);
>> >> 
>> >> 2: make marks and ltt_control use new function
>> >>   example if ltt_control's
>> >>   init() {module_register_callback(LOAD_MODULE, create_debugfs_dir);}
>> >>   exit() {module_unregister_callback(LOAD_MODULE, free_debugfs_dir);}
>> >>   void create_debugfs_dir(struct module *mod) {
>> >>     for (i = 0; i < mod->num_markers; i++ )
>> >>         ...
>> >>     }
>> >> 
>> > 
>> > No, no...
>> > 
>> > only marker_update_probe_range() needs to be called form module.c, at
>> > load_module() and exit_module().
>> > 
>> > It will add a marker entry to the hash table when necessary, and
>> > increment/decrement the reference count of this marker entry. The marker
>> > entry can be removed from the hash table when the refcount falls to 0
>> > and no probe is registered on the marker.
>> > 
>> > At the same time the marker entry is added to the hash table, a
>> > debugfs mkdir is done. When the entry is removed from the hash table, a
>> > debugfs rmdir is done.
>> > 
>> > Is it a bit more clear ?
>> Hi, Mathieu
>> 
>> I see.
>> But IMHO, markers is used by lttng, but is not part of lttng.
>> So, i think source for create files in /debugfs/ltt/... should not be placed in
>> markers.c.
>> 
> 
> Let's put LTTng in /debugfs/trace/ then, along with markers. I think the
> LTTng name will eventually fade away as bits and pieces gets renamed as
> they are merged into mainline. :)
I understood.
OK, Let us try it.

> 
> Mathieu
> 
> 
>> > 
>> > Mathieu
>> > 
>> > 
>> > 
>> > 
>> >> _______________________________________________
>> >> ltt-dev mailing list
>> >> ltt-dev at lists.casi.polymtl.ca
>> >> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>> >> 
>> > 
>> > -- 
>> > Mathieu Desnoyers
>> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
>> > 
>> >
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>> 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> 
>