[ltt-dev] Make lttctl use new interface

[ltt-dev] Make lttctl use new interface

[Mathieu Desnoyers]

* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> Mathieu Desnoyers ??:
> > * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> >> Hi, Mathieu
> >>
> >> I modified lttctl for support debugfs-based ltt-trace-control.
> >>
> >> This patch only modified interior method of control ltt trace,
> >> so command args are not changed.
> >>
> >> We can use this code without modify our user-manual, and lttv need not change
> >> too.
> >>
> >> But personaly, I'd like to design a set of new command arguments for lttctl in
> >> next step, for support each-channel buffer and overwrite control.
> >> And old cmd-args as -X, -V, -B, -z, -x, -v may be dropped(or change for easy
> >> to remember)
> >> For example:
> >> -c Create a trace
> >> -C Create a trace and start
> >> -d Destroy trace channels
> >> -D Stop and destroy trace channels
> >> ...
> >> or
> >> -c  Create a trace
> >> -cs Create a trace and start
> >> -d  Destroy trace channels
> >> -td Terminate and destroy trace channels
> >> ...
> >> But it we do, our unlucky users must read our new manual again : (
> >> What is your opinion?
> >>
> > 
> > Your patch looks great :) But I'd go directly for a command-line
> > breakage so we don't end up keeping legacy options. The sooner the
> > better.
> > 
> > I really like the -c, -C, -d, -D approach. Maybe we could have both of
> > your suggestions supported as aliases ?
> Hello, Mathieu

Hi Zhaolei,

> 
> I consider about following options:
> 
> Basic options:
> -c, --create tracename
> 	Create a trace
> -d, --destroy tracename
> 	Destroy trace channels
> -s, --start tracename
> 	Start tracing

--> terminate -> pause ?

-p, --pause tracename
	Pause tracing

Maybe we should add
  -r --read (comma separated channel list, e.g. -r "cpu,processes")
     Channels to read from
  -w, --write (disk, network, ...)
     Write trace data read from --read channel list through disk or
     network module.

> -h, --help
> 	Show help
> 
> Advanced options:
> --type
> 	Type of trace (ex. relay)
> --ltt_root
> 	LTT channels root path. (ex. /mnt/debugfs/ltt)

sounds good.

> -o, --option
> 	Set options, following operations are supported:
> 	cpu.bufnum=
> 	cpu.bufsize=
> 	cpu.overwrite=
> 	processes.bufnum=
> 	processes.bufsize=
> 	processes.overwrite=
> 	interrupts.bufnum=
> 	interrupts.bufsize=
> 	interrupts.overwrite=
> 	network.bufnum=
> 	network.bufsize=
> 	network.overwrite=
> 	modules.bufnum=
> 	modules.bufsize=
> 	modules.overwrite=
> 	metadata.bufnum=
> 	metadata.bufsize=
> 

Can we more generically say

  <channel>.bufnum=
  <channel>.bufsize=
  <channel>.overwrite=

? Because in a near future we won't be limited to the "fixed" channel
names, other tracers will be allowed to register their own channel.

> Integration options:
> -C, --create_start tracename
>         Create a trace and start
> -D, --stop_destroy tracename

stop -> Pause.
> 	Stop and destroy trace channels

Stop -> Pause. (that's equivalent)

> -A, --all_create tracename
> 	All mode: Create trace, spawn a lttd daemon, start tracing.
> 	(optionally, you can set LTT_DAEMON env. var.)

Yeah, that's not an easy one. I guess "super mega combo pack" would not
be much more descriptive neither. :)

So that would be the -cs -w disk ? (or -C -w disk). Maybe we could leave
that like this (two separate options), I think the -A would be too
confusing.


> -H, --hybrid_finish
> 	Stop tracing, dump flight recorder trace, destroy channels

That would become :

-D -r "list of channels" -w disk

Maybe we could also add a special -r keyword to specify "all overwrite"
or "all non-overwrite" channels. Notice that the standard "hybrid" mode
would be a :

lttctl -C -r "non-overwrite-wildcard" -w disk
...
lttctl -D -r "overwrite-wildcard" -w disk


> -p, --path path
> 	Path for write trace datas. (ex. /root/traces/example_trace)
> 	For -A and -H options

Nope, that would now go with -w option.

> -a, --append
> 	Append to trace
> 	For -A and -H options

This also would go with -w.

> -n, --dump_threads number
> 	Number of lttd threads
> 	For -A and -H options

Same here.

Mathieu

> 
> For example, create and start a trace, set cpu channel's subbuf number to 4,
> set network channel overwrite, and spawn a lttd daemon is:
> lttctl -A trace1 -p /tmp/trace1 -o cpu.bufsize=4 -o network.overwrite=1
> 
> Option of -A(--all_create) looks some strange(not very exact), I'd like to
> find a word means "Do all things for start a trace", do you have some suggestion?
> 
> And option of -H(--hybrid_finish) is not exact too, because I think we should
> make it include meaning of both "finish a trace" and "hybrid", but -H only have
> meaning of "hybrid".
> 
> What is your opinion about options above?
> (Because my English is pool, modify of option's comment is also welcome)
> 
> > 
> > If we change this, we should also update the lttv QUICKSTART file
> > accordingly.
> Yes, lttv also needs little update.
> 
> B.R.
> Zhaolei
> > 
> > Mathieu
> > 
> > 
> 

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

[ltt-dev] Make lttctl use new interface

[Zhaolei]

* From: "Mathieu Desnoyers" <mathieu.desnoyers@polymtl.ca>
>* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>> Mathieu Desnoyers ??:
>> > * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>> >> Hi, Mathieu
>> >>
>> >> I modified lttctl for support debugfs-based ltt-trace-control.
>> >>
>> >> This patch only modified interior method of control ltt trace,
>> >> so command args are not changed.
>> >>
>> >> We can use this code without modify our user-manual, and lttv need not change
>> >> too.
>> >>
>> >> But personaly, I'd like to design a set of new command arguments for lttctl in
>> >> next step, for support each-channel buffer and overwrite control.
>> >> And old cmd-args as -X, -V, -B, -z, -x, -v may be dropped(or change for easy
>> >> to remember)
>> >> For example:
>> >> -c Create a trace
>> >> -C Create a trace and start
>> >> -d Destroy trace channels
>> >> -D Stop and destroy trace channels
>> >> ...
>> >> or
>> >> -c  Create a trace
>> >> -cs Create a trace and start
>> >> -d  Destroy trace channels
>> >> -td Terminate and destroy trace channels
>> >> ...
>> >> But it we do, our unlucky users must read our new manual again : (
>> >> What is your opinion?
>> >>
>> > 
>> > Your patch looks great :) But I'd go directly for a command-line
>> > breakage so we don't end up keeping legacy options. The sooner the
>> > better.
>> > 
>> > I really like the -c, -C, -d, -D approach. Maybe we could have both of
>> > your suggestions supported as aliases ?
>> Hello, Mathieu
> 
> Hi Zhaolei,
> 
>> 
>> I consider about following options:
>> 
>> Basic options:
>> -c, --create tracename
>> Create a trace
>> -d, --destroy tracename
>> Destroy trace channels
>> -s, --start tracename
>> Start tracing
> 
> --> terminate -> pause ?
> 
> -p, --pause tracename
> Pause tracing
> 
> Maybe we should add
>  -r --read (comma separated channel list, e.g. -r "cpu,processes")
>     Channels to read from
>  -w, --write (disk, network, ...)
>     Write trace data read from --read channel list through disk or
>     network module.
> 
>> -h, --help
>> Show help
>> 
>> Advanced options:
>> --type
>> Type of trace (ex. relay)
>> --ltt_root
>> LTT channels root path. (ex. /mnt/debugfs/ltt)
> 
> sounds good.
> 
>> -o, --option
>> Set options, following operations are supported:
>> cpu.bufnum=
>> cpu.bufsize=
>> cpu.overwrite=
>> processes.bufnum=
>> processes.bufsize=
>> processes.overwrite=
>> interrupts.bufnum=
>> interrupts.bufsize=
>> interrupts.overwrite=
>> network.bufnum=
>> network.bufsize=
>> network.overwrite=
>> modules.bufnum=
>> modules.bufsize=
>> modules.overwrite=
>> metadata.bufnum=
>> metadata.bufsize=
>> 
> 
> Can we more generically say
> 
>  <channel>.bufnum=
>  <channel>.bufsize=
>  <channel>.overwrite=
> 
> ? Because in a near future we won't be limited to the "fixed" channel
> names, other tracers will be allowed to register their own channel.
> 
>> Integration options:
>> -C, --create_start tracename
>>         Create a trace and start
>> -D, --stop_destroy tracename
> 
> stop -> Pause.
>> Stop and destroy trace channels
> 
> Stop -> Pause. (that's equivalent)
> 
>> -A, --all_create tracename
>> All mode: Create trace, spawn a lttd daemon, start tracing.
>> (optionally, you can set LTT_DAEMON env. var.)
> 
> Yeah, that's not an easy one. I guess "super mega combo pack" would not
> be much more descriptive neither. :)
> 
> So that would be the -cs -w disk ? (or -C -w disk). Maybe we could leave
> that like this (two separate options), I think the -A would be too
> confusing.
> 
> 
>> -H, --hybrid_finish
>> Stop tracing, dump flight recorder trace, destroy channels
> 
> That would become :
> 
> -D -r "list of channels" -w disk
> 
> Maybe we could also add a special -r keyword to specify "all overwrite"
> or "all non-overwrite" channels. Notice that the standard "hybrid" mode
> would be a :
> 
> lttctl -C -r "non-overwrite-wildcard" -w disk
> ...
> lttctl -D -r "overwrite-wildcard" -w disk
> 
Hello, Mathieu

Thanks for your suggestion.

I think -r must specify non-overwrite channels with -C, and must specify
overwrite channels with -D.

Instead of select some channel to dump, why not just trace some of channel,
then we can dump all non-overwrite channels with -C and dump all overwrite
channels with -D.

For example:
Trace network and process channel with non-overwrite mode, and trace cpu channel
with overwrite mode, other channel are not traced when we start a new trace.
Then we can dump all non-overwrite channels(network and process channel)
in tracing, and dump all overwrite channels(cpu channel) when we finished trace.

It can reduce system load when we only want to trace some channels.

B.R.
Zhaolei

> 
>> -p, --path path
>> Path for write trace datas. (ex. /root/traces/example_trace)
>> For -A and -H options
> 
> Nope, that would now go with -w option.
> 
>> -a, --append
>> Append to trace
>> For -A and -H options
> 
> This also would go with -w.
> 
>> -n, --dump_threads number
>> Number of lttd threads
>> For -A and -H options
> 
> Same here.
> 
> Mathieu
> 
>> 
>> For example, create and start a trace, set cpu channel's subbuf number to 4,
>> set network channel overwrite, and spawn a lttd daemon is:
>> lttctl -A trace1 -p /tmp/trace1 -o cpu.bufsize=4 -o network.overwrite=1
>> 
>> Option of -A(--all_create) looks some strange(not very exact), I'd like to
>> find a word means "Do all things for start a trace", do you have some suggestion?
>> 
>> And option of -H(--hybrid_finish) is not exact too, because I think we should
>> make it include meaning of both "finish a trace" and "hybrid", but -H only have
>> meaning of "hybrid".
>> 
>> What is your opinion about options above?
>> (Because my English is pool, modify of option's comment is also welcome)
>> 
>> > 
>> > If we change this, we should also update the lttv QUICKSTART file
>> > accordingly.
>> Yes, lttv also needs little update.
>> 
>> B.R.
>> Zhaolei
>> > 
>> > Mathieu
>> > 
>> > 
>> 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> 
>

[ltt-dev] Make lttctl use new interface

[Mathieu Desnoyers]

* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> * From: "Mathieu Desnoyers" <mathieu.desnoyers@polymtl.ca>
> >* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> >> Mathieu Desnoyers ??:
> >> > * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> >> >> Hi, Mathieu
> >> >>
> >> >> I modified lttctl for support debugfs-based ltt-trace-control.
> >> >>
> >> >> This patch only modified interior method of control ltt trace,
> >> >> so command args are not changed.
> >> >>
> >> >> We can use this code without modify our user-manual, and lttv need not change
> >> >> too.
> >> >>
> >> >> But personaly, I'd like to design a set of new command arguments for lttctl in
> >> >> next step, for support each-channel buffer and overwrite control.
> >> >> And old cmd-args as -X, -V, -B, -z, -x, -v may be dropped(or change for easy
> >> >> to remember)
> >> >> For example:
> >> >> -c Create a trace
> >> >> -C Create a trace and start
> >> >> -d Destroy trace channels
> >> >> -D Stop and destroy trace channels
> >> >> ...
> >> >> or
> >> >> -c  Create a trace
> >> >> -cs Create a trace and start
> >> >> -d  Destroy trace channels
> >> >> -td Terminate and destroy trace channels
> >> >> ...
> >> >> But it we do, our unlucky users must read our new manual again : (
> >> >> What is your opinion?
> >> >>
> >> > 
> >> > Your patch looks great :) But I'd go directly for a command-line
> >> > breakage so we don't end up keeping legacy options. The sooner the
> >> > better.
> >> > 
> >> > I really like the -c, -C, -d, -D approach. Maybe we could have both of
> >> > your suggestions supported as aliases ?
> >> Hello, Mathieu
> > 
> > Hi Zhaolei,
> > 
> >> 
> >> I consider about following options:
> >> 
> >> Basic options:
> >> -c, --create tracename
> >> Create a trace
> >> -d, --destroy tracename
> >> Destroy trace channels
> >> -s, --start tracename
> >> Start tracing
> > 
> > --> terminate -> pause ?
> > 
> > -p, --pause tracename
> > Pause tracing
> > 
> > Maybe we should add
> >  -r --read (comma separated channel list, e.g. -r "cpu,processes")
> >     Channels to read from
> >  -w, --write (disk, network, ...)
> >     Write trace data read from --read channel list through disk or
> >     network module.
> > 
> >> -h, --help
> >> Show help
> >> 
> >> Advanced options:
> >> --type
> >> Type of trace (ex. relay)
> >> --ltt_root
> >> LTT channels root path. (ex. /mnt/debugfs/ltt)
> > 
> > sounds good.
> > 
> >> -o, --option
> >> Set options, following operations are supported:
> >> cpu.bufnum=
> >> cpu.bufsize=
> >> cpu.overwrite=
> >> processes.bufnum=
> >> processes.bufsize=
> >> processes.overwrite=
> >> interrupts.bufnum=
> >> interrupts.bufsize=
> >> interrupts.overwrite=
> >> network.bufnum=
> >> network.bufsize=
> >> network.overwrite=
> >> modules.bufnum=
> >> modules.bufsize=
> >> modules.overwrite=
> >> metadata.bufnum=
> >> metadata.bufsize=
> >> 
> > 
> > Can we more generically say
> > 
> >  <channel>.bufnum=
> >  <channel>.bufsize=
> >  <channel>.overwrite=
> > 
> > ? Because in a near future we won't be limited to the "fixed" channel
> > names, other tracers will be allowed to register their own channel.
> > 
> >> Integration options:
> >> -C, --create_start tracename
> >>         Create a trace and start
> >> -D, --stop_destroy tracename
> > 
> > stop -> Pause.
> >> Stop and destroy trace channels
> > 
> > Stop -> Pause. (that's equivalent)
> > 
> >> -A, --all_create tracename
> >> All mode: Create trace, spawn a lttd daemon, start tracing.
> >> (optionally, you can set LTT_DAEMON env. var.)
> > 
> > Yeah, that's not an easy one. I guess "super mega combo pack" would not
> > be much more descriptive neither. :)
> > 
> > So that would be the -cs -w disk ? (or -C -w disk). Maybe we could leave
> > that like this (two separate options), I think the -A would be too
> > confusing.
> > 
> > 
> >> -H, --hybrid_finish
> >> Stop tracing, dump flight recorder trace, destroy channels
> > 
> > That would become :
> > 
> > -D -r "list of channels" -w disk
> > 
> > Maybe we could also add a special -r keyword to specify "all overwrite"
> > or "all non-overwrite" channels. Notice that the standard "hybrid" mode
> > would be a :
> > 
> > lttctl -C -r "non-overwrite-wildcard" -w disk
> > ...
> > lttctl -D -r "overwrite-wildcard" -w disk
> > 
> Hello, Mathieu
> 
> Thanks for your suggestion.
> 
> I think -r must specify non-overwrite channels with -C, and must specify
> overwrite channels with -D.
> 
> Instead of select some channel to dump, why not just trace some of channel,
> then we can dump all non-overwrite channels with -C and dump all overwrite
> channels with -D.
> 
> For example:
> Trace network and process channel with non-overwrite mode, and trace cpu channel
> with overwrite mode, other channel are not traced when we start a new trace.
> Then we can dump all non-overwrite channels(network and process channel)
> in tracing, and dump all overwrite channels(cpu channel) when we finished trace.
> 
> It can reduce system load when we only want to trace some channels.
> 
> B.R.
> Zhaolei
> 


Yep, it looks good and easy to understand.

Mathieu

> > 
> >> -p, --path path
> >> Path for write trace datas. (ex. /root/traces/example_trace)
> >> For -A and -H options
> > 
> > Nope, that would now go with -w option.
> > 
> >> -a, --append
> >> Append to trace
> >> For -A and -H options
> > 
> > This also would go with -w.
> > 
> >> -n, --dump_threads number
> >> Number of lttd threads
> >> For -A and -H options
> > 
> > Same here.
> > 
> > Mathieu
> > 
> >> 
> >> For example, create and start a trace, set cpu channel's subbuf number to 4,
> >> set network channel overwrite, and spawn a lttd daemon is:
> >> lttctl -A trace1 -p /tmp/trace1 -o cpu.bufsize=4 -o network.overwrite=1
> >> 
> >> Option of -A(--all_create) looks some strange(not very exact), I'd like to
> >> find a word means "Do all things for start a trace", do you have some suggestion?
> >> 
> >> And option of -H(--hybrid_finish) is not exact too, because I think we should
> >> make it include meaning of both "finish a trace" and "hybrid", but -H only have
> >> meaning of "hybrid".
> >> 
> >> What is your opinion about options above?
> >> (Because my English is pool, modify of option's comment is also welcome)
> >> 
> >> > 
> >> > If we change this, we should also update the lttv QUICKSTART file
> >> > accordingly.
> >> Yes, lttv also needs little update.
> >> 
> >> B.R.
> >> Zhaolei
> >> > 
> >> > 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