[ltt-dev] [PATCH] Separateltt_trace_create()intoltt_trace_create() and ltt_trace_alloc()

[Mathieu Desnoyers]

* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> *Mathieu wrote:
> >* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> >> `-- debugfs
> >>     `-- ltt
> >>         |-- buffers
> >>         |   `-- ...
> >>         |-- control
> >>         |   `-- trace1
> >>         |       |-- alloc
> >>         |       |-- channel
> >>         |       |   |-- control
> >>         |       |   |   |-- interrupts
> >>         |       |   |   |   |-- subbuf_num
> >>         |       |   |   |   `-- subbuf_size
> >>         |       |   |   |-- metadata
> >>         |       |   |   |   |-- subbuf_num
> >>         |       |   |   |   `-- subbuf_size
> >>         |       |   |   |-- modules
> >>         |       |   |   |   |-- subbuf_num
> >>         |       |   |   |   `-- subbuf_size
> >>         |       |   |   |-- network
> >>         |       |   |   |   |-- subbuf_num
> >>         |       |   |   |   `-- subbuf_size
> >>         |       |   |   `-- processes
> >>         |       |   |       |-- subbuf_num
> >>         |       |   |       `-- subbuf_size
> >>         |       |   `-- cpu
> >>         |       |       |-- mode
> >>         |       |       |-- subbuf_num
> >>         |       |       `-- subbuf_size
> >>         |       `-- enabled
> >>         `-- setup_trace
> >> 
> >> It lakes control-file for destroy a trace and setup trace_type.
> >> So I think we should change tree struct as follow,
> >> Do you hace some comment?
> >> 
> >> `-- debugfs
> >>     `-- ltt
> >>         |-- buffers
> >>         |   `-- ...
> >>         |-- control
> >>         |   `-- trace1
> >>         |       |-- alloc
> > 
> > echo 1 > alloc -> allocate
> > echo 0 > alloc -> free ?
> > 
> Hello, Mathieu,
> Thanks for your answer.
> >>         |       |-- channel
> >>         |       |   |-- control
> >>         |       |   |   |-- interrupts
> >>         |       |   |   |   |-- subbuf_num
> >>         |       |   |   |   `-- subbuf_size
> >                              \-- overwrite (1/0)
> >>         |       |   |   |-- metadata
> >>         |       |   |   |   |-- subbuf_num
> >>         |       |   |   |   `-- subbuf_size
> >                              \-- overwrite
> >>         |       |   |   |-- modules
> >>         |       |   |   |   |-- subbuf_num
> >>         |       |   |   |   `-- subbuf_size
> >                              \-- overwrite
> >>         |       |   |   |-- network
> >>         |       |   |   |   |-- subbuf_num
> >>         |       |   |   |   `-- subbuf_size
> >                              \-- overwrite
> >>         |       |   |   `-- processes
> >>         |       |   |       |-- subbuf_num
> >>         |       |   |       `-- subbuf_size
> >                              \-- overwrite
> >>         |       |   `-- cpu
> >>         |       |       |-- mode
> >>         |       |       |-- subbuf_num
> >>         |       |       `-- subbuf_size
> >>         |       |-- enabled
> >>         |       `-- type ******new******
> > 
> > Nope, the overwrite above will be more flexible. Then people can select
> > per-channel which one they want in flight recorder mode (overwrite = 1).
> > Default would be non-flight (normal mode, overwrite = 0). Hybrid is
> > really just a combination of the two.
> > 
> > Note that the metadata channel must be forced to "normal" mode. This is
> > a special-case.
> "type" in my question means const char *type in:
> static int ltt_trace_create(const char *trace_name, const char *trace_type,
>     enum trace_mode mode,
>     unsigned subbuf_size_low, unsigned n_subbufs_low,
>     unsigned subbuf_size_med, unsigned n_subbufs_med,
>     unsigned subbuf_size_high, unsigned n_subbufs_high);
> 
> Its value is "relay" and "relay-locked", so i think we can add a control file named:
> /debugfs/ltt/control/trace_name/channel/type (or  transport) for it.
> 
> And, we will add function for set each channel's overwrite, so control tree will be:
> 
> `-- debugfs
>     `-- ltt
>         |-- buffers
>         |   `-- ...
>         |-- control
>         |   `-- trace1
>         |       |-- alloc
>         |       |-- channel
>         |       |   |-- control
>         |       |   |   |-- interrupts
>         |       |   |   |   |-- subbuf_num
>         |       |   |   |   |-- subbuf_size
>         |       |   |   |   `-- overwrite
>         |       |   |   |-- metadata
>         |       |   |   |   |-- subbuf_num
>         |       |   |   |   |-- subbuf_size
>         |       |   |   |   `-- overwrite
>         |       |   |   |-- modules
>         |       |   |   |   |-- subbuf_num
>         |       |   |   |   |-- subbuf_size
>         |       |   |   |   `-- overwrite
>         |       |   |   |-- network
>         |       |   |   |   |-- subbuf_num
>         |       |   |   |   |-- subbuf_size
>         |       |   |   |   `-- overwrite
>         |       |   |   `-- processes
>         |       |   |       |-- subbuf_num
>         |       |   |       |-- subbuf_size
>         |       |   |       `-- overwrite
>         |       |   `-- cpu
>         |       |       |-- subbuf_num
>         |       |       |-- subbuf_size
>         |       |       `-- overwrite
>         |       |-- enabled
>         |       `-- transport
>          `-- setup_trace
> 
> Changes are:
> 1: add transport to set ltt_trace_create()'s const char *trace_type.
> 2: delete cpu's mode file
> 3: add overwrite for each channel include cpu.
> 
> Questions:
> 1: make echo 1 > metadata/overwrite return error (*it is my prefer)
>    OR
>    make metadata/overwrite non-exist?

Hi Zhaolei,

Sorry for late answer, I've been very busy last week,

Hrm, I have no strong opinion on this one. I think having the same
layout for every channel makes sense, and returning errors when
operations are done on them when they are not supposed to is ok.

> 2: Why we put channel of cpu in channel/control/?
>    it looks some complex for user.

Hrm, yes, good point. control/ is probably unneeded and too much
division into subdirs, so I guess we can do without it.

> 
> btw:
> Following mail failed sending to you because our mail-server.
> Cound you tell your opinion of this mail?
> (you can see it in ltt-ml)

You server at Fujitsu seems to have problems resolving my
krystal.dyndns.org address. The problem does not seem to be on my side.
Your IT service should probably check that the DNS servers works
correctly.

Mathieu

> Date: Wed, 29 Oct 2008 12:04:30 +0800
> To: Mathieu Desnoyers <compudj at krystal.dyndns.org>
> Cc: ltt-dev at lists.casi.polymtl.ca
> X-Mailer: Microsoft Outlook Express 6.00.2900.5512
> From: Zhaolei <zhaolei at cn.fujitsu.com>
> Subject: Re: [ltt-dev] [PATCH] Separate ltt_trace_create()
> intoltt_trace_create() and ltt_trace_alloc()
> _______________________________________________
> 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