From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Tue, 28 Oct 2008 23:19:45 -0400
Subject: [ltt-dev] Updated TODO list before releasing LTTng buffering	to
	LKML
In-Reply-To: <48A9612F918F4C2CAE3A6A6BB05F52A6@zhaoleiwin>
References: <20081028152143.GD1136@Krystal>
	<48A9612F918F4C2CAE3A6A6BB05F52A6@zhaoleiwin>
Message-ID: <20081029031945.GA1425@Krystal>

* 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