Re: [RFC V2 PATCH]debugfs:Fix terminology inconsistency of dir name to mount debugfs filesystem.

From: GeunSik Lim
Date: Sat May 30 2009 - 05:38:48 EST


On Sat, May 30, 2009 at 11:28 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Sat, 30 May 2009, GeunSik Lim wrote:
>
>> Thanks your advice. I agree with your reply about this patch.
>> I updated contents that you advised like belows.
>> If I mistake, Please correct me.
>>
>> And, I also need your review Âabout below 2 contents in the ftrace.txt file.
>>
>> Thanks,
>> GeunSik Lim.
>>
>>
>> 1)
>> @@ -1146,7 +1158,7 @@ int trace_fd;
>> Â[...]
>> Âint main(int argc, char *argv[]) {
>> Â Â Â [...]
>> - Â Â trace_fd = open("/debug/tracing/tracing_enabled", O_WRONLY);
>> + Â Â trace_fd = open("/sys/kernel/debug/tracing/tracing_enabled", O_WRONLY);
>> Â Â Â [...]
>> Â Â Â if (condition_hit()) {
>> Â Â Â Â Â Â Â write(trace_fd, "0", 1);
>> @@ -1154,26 +1166,23 @@ int main(int argc, char *argv[]) {
>> Â Â Â [...]
>> Â}
>>
>>
>> @@ -1217,12 +1226,12 @@ int main (int argc, char **argv)
>> Â Â Â Â Â Â Â Â Âchar line[64];
>> Â Â Â Â Â Â Â Â Âint s;
>>
>> - Â Â Â Â Â Â Â Âffd = open("/debug/tracing/current_tracer", O_WRONLY);
>> + Â Â Â Â Â Â Â Âffd =
>> open("/sys/kernel/debug/tracing/current_tracer", O_WRONLY);
>> Â Â Â Â Â Â Â Â Âif (ffd < 0)
>> Â Â Â Â Â Â Â Â Â Â Â Â Âexit(-1);
>> Â Â Â Â Â Â Â Â Âwrite(ffd, "nop", 3);
>>
>> - Â Â Â Â Â Â Â Âfd = open("/debug/tracing/set_ftrace_pid", O_WRONLY);
>> + Â Â Â Â Â Â Â Âfd = open("/sys/kernel/debug/tracing/set_ftrace_pid",
>> O_WRONLY);
>> Â Â Â Â Â Â Â Â Âs = sprintf(line, "%d\n", getpid());
>> Â Â Â Â Â Â Â Â Âwrite(fd, line, s);
>> -Note: Here we hard coded the path name. The debugfs mount is not
>> -guaranteed to be at /debug (and is more commonly at
>> -/sys/kernel/debug). For simple one time traces, the above is
>> -sufficent. For anything else, a search through /proc/mounts may
>> +Note: Here we hard coded the path name. A search through /proc/mounts may
>> Âbe needed to find where the debugfs file-system is mounted.
>
> Here's the function I use:
>
> #define _STR(x) x
> #define STR(x) _STR(x)
> #define MAX_PATH 256
>
> const char *find_debugfs(void)
> {
> Â Â Â Âstatic char debugfs[MAX_PATH+1];
> Â Â Â Âstatic int debugfs_found;
> Â Â Â Âchar type[100];
> Â Â Â ÂFILE *fp;
>
> Â Â Â Âif (debugfs_found)
> Â Â Â Â Â Â Â Âreturn debugfs;
>
>
> Â Â Â Âif ((fp = fopen("/proc/mounts","r")) == NULL) {
> Â Â Â Â Â Â Â Âperror("/proc/mounts");
> Â Â Â Â Â Â Â Âreturn NULL;
> Â Â Â Â}
>
> Â Â Â Âwhile (fscanf(fp, "%*s %"
> Â Â Â Â Â Â Â Â Â Â ÂSTR(MAX_PATH)
> Â Â Â Â Â Â Â Â Â Â Â"s %99s %*s %*d %*d\n",
> Â Â Â Â Â Â Â Â Â Â Âdebugfs, type) == 2) {
> Â Â Â Â Â Â Â Âif (strcmp(type, "debugfs") == 0)
> Â Â Â Â Â Â Â Â Â Â Â Âbreak;
> Â Â Â Â}
> Â Â Â Âfclose(fp);
>
> Â Â Â Âif (strcmp(type, "debugfs") != 0) {
> Â Â Â Â Â Â Â Âfprintf(stderr, "debugfs not mounted");
> Â Â Â Â Â Â Â Âreturn NULL;
> Â Â Â Â}
>
> Â Â Â Âdebugfs_found = 1;
>
> Â Â Â Âreturn debugfs;
> }
>
> This might be a good idea to show it. This is the most robust since it
> does not hard code the debugfs directory.
Yes, I think so. I have one opinion in the above find_debugfs() function.
Default directory is "/sys/kernel/debug/tracing" in ftrace.txt file
as you mentioned.
I will append below code for "***/tracing/" directory name.

int size;
[...]
size = MAX_PATH - strlen(debugfs);
strncat(debugfs, "/tracing/", size);
return debugfs;
>
>>
>> 2)
>> More details can be found in the source code, in the
>> -kernel/tracing/*.c files.
>> +kernel/trace/*.c files
>>
>>
>>
>> * about ftrace.txt file
>> ---
>> diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
>> index fd9a3e6..790199b 100644
>> --- a/Documentation/trace/ftrace.txt
>> +++ b/Documentation/trace/ftrace.txt
>> @@ -7,7 +7,6 @@ Copyright 2008 Red Hat Inc.
>> Â Â Â Â Â Â Â Â (dual licensed under the GPL v2)
>> ÂReviewers: Â Elias Oltmanns, Randy Dunlap, Andrew Morton,
>> Â Â Â Â Â ÂJohn Kacur, and David Teigland.
>> -
>> ÂWritten for: 2.6.28-rc2
>>
>> ÂIntroduction
>> @@ -33,13 +32,26 @@ The File System
>> ÂFtrace uses the debugfs file system to hold the control files as
>> Âwell as the files to display output.
>>
>> -To mount the debugfs system:
>> +When debugfs is configured into the kernel (which selecting any ftrace
>> +option will do) the directory /sys/kernel/debug will be created. To mount
>> +this directory, you can add to your /etc/fstab file:
>> +
>> + debugfs    /sys/kernel/debug     Âdebugfs defaults    Â0    0
>> +
>> +Or you can mount it at run time with:
>> +
>> + mount -t debugfs nodev /sys/kernel/debug
>> +
>> +For quicker access to that directory you may want to make a soft link to
>> +it:
>>
>> - Â# mkdir /debug
>> - Â# mount -t debugfs nodev /debug
>> + ln -s /sys/kernel/debug /debug
>>
>> -( Note: it is more common to mount at /sys/kernel/debug, but for
>> - Âsimplicity this document will use /debug)
>> +Any selected ftrace option will also create a directory called tracing
>> +within the debugfs. The rest of the document will assume that you are in
>> +the ftrace directory (cd /sys/kernel/debug/tracing) and will only concentrate
>> +on the files within that directory and not distract from the content with
>> +the extended "/sys/kernel/debug/tracing" path name.
>>
>> ÂThat's it! (assuming that you have ftrace configured into your kernel)
>>
>> @@ -389,18 +401,18 @@ trace_options
>> ÂThe trace_options file is used to control what gets printed in
>> Âthe trace output. To see what is available, simply cat the file:
>>
>> - Âcat /debug/tracing/trace_options
>> + Âcat ./trace_options
>
> Please remove the "./", it is also distracting. We state that we "cd" to
> the location. "cat trace_options" is good enough.
It's right. This is just my private style. I will remove "./".
>
> Same for the all the others below.
>
> Also, since I'm the most picky about this, you may want to remove the
> ftrace files from the patch and move it to another patch. That way the
I am not think that you are the most picky about this. I like your advice and
review about my proposal for consensus.
> owners of the other files can ack them and get those changes in. When we
> have something for ftrace, I'll give my ack. But lets not hold up the
> other changes because of me ;-)
>
Don't care. Hope it helps. ;-)
I will modify ftrace files from the patch according to your advice.

> -- Steve
>
>> Â Âprint-parent nosym-offset nosym-addr noverbose noraw nohex nobin \
>> Â Ânoblock nostacktrace nosched-tree nouserstacktrace nosym-userobj
>>
>> ÂTo disable one of the options, echo in the option prepended with
>> Â"no".
>>
>> - Âecho noprint-parent > /debug/tracing/trace_options
>> + Âecho noprint-parent > ./trace_options
>>
>> ÂTo enable an option, leave off the "no".
>>
>> - Âecho sym-offset > /debug/tracing/trace_options
>> + Âecho sym-offset > ./trace_options
>>
>> ÂHere are the available options:
>>
>> @@ -476,11 +488,11 @@ sched_switch
>> ÂThis tracer simply records schedule switches. Here is an example
>> Âof how to use it.
>>
>> - # echo sched_switch > /debug/tracing/current_tracer
>> - # echo 1 > /debug/tracing/tracing_enabled
>> + # echo sched_switch > ./current_tracer
>> + # echo 1 > ./tracing_enabled
>> Â # sleep 1
>> - # echo 0 > /debug/tracing/tracing_enabled
>> - # cat /debug/tracing/trace
>> + # echo 0 > ./tracing_enabled
>> + # cat ./trace
>>
>> Â# tracer: sched_switch
>> Â#
>> @@ -574,13 +586,13 @@ new trace is saved.
>> ÂTo reset the maximum, echo 0 into tracing_max_latency. Here is
>> Âan example:
>>
>> - # echo irqsoff > /debug/tracing/current_tracer
>> - # echo 0 > /debug/tracing/tracing_max_latency
>> - # echo 1 > /debug/tracing/tracing_enabled
>> + # echo irqsoff > ./current_tracer
>> + # echo 0 > ./tracing_max_latency
>> + # echo 1 > ./tracing_enabled
>> Â # ls -ltr
>> Â [...]
>> - # echo 0 > /debug/tracing/tracing_enabled
>> - # cat /debug/tracing/latency_trace
>> + # echo 0 > ./tracing_enabled
>> + # cat ./latency_trace
>> Â# tracer: irqsoff
>> Â#
>> Âirqsoff latency trace v1.1.5 on 2.6.26
>> @@ -681,13 +693,13 @@ Like the irqsoff tracer, it records the maximum
>> latency for
>> Âwhich preemption was disabled. The control of preemptoff tracer
>> Âis much like the irqsoff tracer.
>>
>> - # echo preemptoff > /debug/tracing/current_tracer
>> - # echo 0 > /debug/tracing/tracing_max_latency
>> - # echo 1 > /debug/tracing/tracing_enabled
>> + # echo preemptoff > ./current_tracer
>> + # echo 0 > ./tracing_max_latency
>> + # echo 1 > ./tracing_enabled
>> Â # ls -ltr
>> Â [...]
>> - # echo 0 > /debug/tracing/tracing_enabled
>> - # cat /debug/tracing/latency_trace
>> + # echo 0 > ./tracing_enabled
>> + # cat ./latency_trace
>> Â# tracer: preemptoff
>> Â#
>> Âpreemptoff latency trace v1.1.5 on 2.6.26-rc8
>> @@ -828,13 +840,13 @@ tracer.
>> ÂAgain, using this trace is much like the irqsoff and preemptoff
>> Âtracers.
>>
>> - # echo preemptirqsoff > /debug/tracing/current_tracer
>> - # echo 0 > /debug/tracing/tracing_max_latency
>> - # echo 1 > /debug/tracing/tracing_enabled
>> + # echo preemptirqsoff > ./current_tracer
>> + # echo 0 > ./tracing_max_latency
>> + # echo 1 > ./tracing_enabled
>> Â # ls -ltr
>> Â [...]
>> - # echo 0 > /debug/tracing/tracing_enabled
>> - # cat /debug/tracing/latency_trace
>> + # echo 0 > ./tracing_enabled
>> + # cat ./latency_trace
>> Â# tracer: preemptirqsoff
>> Â#
>> Âpreemptirqsoff latency trace v1.1.5 on 2.6.26-rc8
>> @@ -990,12 +1002,12 @@ slightly differently than we did with the
>> previous tracers.
>> ÂInstead of performing an 'ls', we will run 'sleep 1' under
>> Â'chrt' which changes the priority of the task.
>>
>> - # echo wakeup > /debug/tracing/current_tracer
>> - # echo 0 > /debug/tracing/tracing_max_latency
>> - # echo 1 > /debug/tracing/tracing_enabled
>> + # echo wakeup > ./current_tracer
>> + # echo 0 > ./tracing_max_latency
>> + # echo 1 > ./tracing_enabled
>> Â # chrt -f 5 sleep 1
>> - # echo 0 > /debug/tracing/tracing_enabled
>> - # cat /debug/tracing/latency_trace
>> + # echo 0 > ./tracing_enabled
>> + # cat ./latency_trace
>> Â# tracer: wakeup
>> Â#
>> Âwakeup latency trace v1.1.5 on 2.6.26-rc8
>> @@ -1105,11 +1117,11 @@ can be done from the debug file system. Make sure the
>> Âftrace_enabled is set; otherwise this tracer is a nop.
>>
>> Â # sysctl kernel.ftrace_enabled=1
>> - # echo function > /debug/tracing/current_tracer
>> - # echo 1 > /debug/tracing/tracing_enabled
>> + # echo function > ./current_tracer
>> + # echo 1 > ./tracing_enabled
>> Â # usleep 1
>> - # echo 0 > /debug/tracing/tracing_enabled
>> - # cat /debug/tracing/trace
>> + # echo 0 > ./tracing_enabled
>> + # cat ./trace
>> Â# tracer: function
>> Â#
>> Â# Â Â Â Â Â TASK-PID Â CPU# Â ÂTIMESTAMP ÂFUNCTION
>> @@ -1146,7 +1158,7 @@ int trace_fd;
>> Â[...]
>> Âint main(int argc, char *argv[]) {
>> Â Â Â [...]
>> - Â Â trace_fd = open("/debug/tracing/tracing_enabled", O_WRONLY);
>> + Â Â trace_fd = open("/sys/kernel/debug/tracing/tracing_enabled", O_WRONLY);
>> Â Â Â [...]
>> Â Â Â if (condition_hit()) {
>> Â Â Â Â Â Â Â write(trace_fd, "0", 1);
>> @@ -1154,26 +1166,23 @@ int main(int argc, char *argv[]) {
>> Â Â Â [...]
>> Â}
>>
>> -Note: Here we hard coded the path name. The debugfs mount is not
>> -guaranteed to be at /debug (and is more commonly at
>> -/sys/kernel/debug). For simple one time traces, the above is
>> -sufficent. For anything else, a search through /proc/mounts may
>> +Note: Here we hard coded the path name. A search through /proc/mounts may
>> Âbe needed to find where the debugfs file-system is mounted.
>>
>>
>> ÂSingle thread tracing
>> Â---------------------
>>
>> -By writing into /debug/tracing/set_ftrace_pid you can trace a
>> +By writing into ./set_ftrace_pid you can trace a
>> Âsingle thread. For example:
>>
>> -# cat /debug/tracing/set_ftrace_pid
>> +# cat ./set_ftrace_pid
>> Âno pid
>> -# echo 3111 > /debug/tracing/set_ftrace_pid
>> -# cat /debug/tracing/set_ftrace_pid
>> +# echo 3111 > ./set_ftrace_pid
>> +# cat ./set_ftrace_pid
>> Â3111
>> -# echo function > /debug/tracing/current_tracer
>> -# cat /debug/tracing/trace | head
>> +# echo function > ./current_tracer
>> +# cat ./trace | head
>> Â # tracer: function
>> Â #
>> Â # Â Â Â Â Â TASK-PID Â ÂCPU# Â ÂTIMESTAMP ÂFUNCTION
>> @@ -1184,8 +1193,8 @@ no pid
>> Â Â Â yum-updatesd-3111 Â[003] Â1637.254683: lock_hrtimer_base
>> <-hrtimer_try_to_cancel
>> Â Â Â yum-updatesd-3111 Â[003] Â1637.254685: fget_light <-do_sys_poll
>> Â Â Â yum-updatesd-3111 Â[003] Â1637.254686: pipe_poll <-do_sys_poll
>> -# echo -1 > /debug/tracing/set_ftrace_pid
>> -# cat /debug/tracing/trace |head
>> +# echo -1 > ./set_ftrace_pid
>> +# cat ./trace |head
>> Â # tracer: function
>> Â #
>> Â # Â Â Â Â Â TASK-PID Â ÂCPU# Â ÂTIMESTAMP ÂFUNCTION
>> @@ -1217,12 +1226,12 @@ int main (int argc, char **argv)
>> Â Â Â Â Â Â Â Â Âchar line[64];
>> Â Â Â Â Â Â Â Â Âint s;
>>
>> - Â Â Â Â Â Â Â Âffd = open("/debug/tracing/current_tracer", O_WRONLY);
>> + Â Â Â Â Â Â Â Âffd =
>> open("/sys/kernel/debug/tracing/current_tracer", O_WRONLY);
>> Â Â Â Â Â Â Â Â Âif (ffd < 0)
>> Â Â Â Â Â Â Â Â Â Â Â Â Âexit(-1);
>> Â Â Â Â Â Â Â Â Âwrite(ffd, "nop", 3);
>>
>> - Â Â Â Â Â Â Â Âfd = open("/debug/tracing/set_ftrace_pid", O_WRONLY);
>> + Â Â Â Â Â Â Â Âfd = open("/sys/kernel/debug/tracing/set_ftrace_pid",
>> O_WRONLY);
>> Â Â Â Â Â Â Â Â Âs = sprintf(line, "%d\n", getpid());
>> Â Â Â Â Â Â Â Â Âwrite(fd, line, s);
>>
>> @@ -1374,22 +1383,22 @@ want, depending on your needs.
>> Â Âtracing_cpu_mask file) or you might sometimes see unordered
>> Â Âfunction calls while cpu tracing switch.
>>
>> - Â Â hide: echo nofuncgraph-cpu > /debug/tracing/trace_options
>> - Â Â show: echo funcgraph-cpu > /debug/tracing/trace_options
>> + Â Â hide: echo nofuncgraph-cpu > ./trace_options
>> + Â Â show: echo funcgraph-cpu > ./trace_options
>>
>> Â- The duration (function's time of execution) is displayed on
>> Â Âthe closing bracket line of a function or on the same line
>> Â Âthan the current function in case of a leaf one. It is default
>> Â Âenabled.
>>
>> - Â Â hide: echo nofuncgraph-duration > /debug/tracing/trace_options
>> - Â Â show: echo funcgraph-duration > /debug/tracing/trace_options
>> + Â Â hide: echo nofuncgraph-duration > ./trace_options
>> + Â Â show: echo funcgraph-duration > ./trace_options
>>
>> Â- The overhead field precedes the duration field in case of
>> Â Âreached duration thresholds.
>>
>> - Â Â hide: echo nofuncgraph-overhead > /debug/tracing/trace_options
>> - Â Â show: echo funcgraph-overhead > /debug/tracing/trace_options
>> + Â Â hide: echo nofuncgraph-overhead > ./trace_options
>> + Â Â show: echo funcgraph-overhead > ./trace_options
>> Â Â Â depends on: funcgraph-duration
>>
>> Â Âie:
>> @@ -1418,8 +1427,8 @@ want, depending on your needs.
>> Â- The task/pid field displays the thread cmdline and pid which
>> Â Âexecuted the function. It is default disabled.
>>
>> - Â Â hide: echo nofuncgraph-proc > /debug/tracing/trace_options
>> - Â Â show: echo funcgraph-proc > /debug/tracing/trace_options
>> + Â Â hide: echo nofuncgraph-proc > ./trace_options
>> + Â Â show: echo funcgraph-proc > ./trace_options
>>
>> Â Âie:
>>
>> @@ -1442,8 +1451,8 @@ want, depending on your needs.
>> Â Âsystem clock since it started. A snapshot of this time is
>> Â Âgiven on each entry/exit of functions
>>
>> - Â Â hide: echo nofuncgraph-abstime > /debug/tracing/trace_options
>> - Â Â show: echo funcgraph-abstime > /debug/tracing/trace_options
>> + Â Â hide: echo nofuncgraph-abstime > ./trace_options
>> + Â Â show: echo funcgraph-abstime > ./trace_options
>>
>> Â Âie:
>>
>> @@ -1540,7 +1549,7 @@ listed in:
>>
>> Â Â available_filter_functions
>>
>> - # cat /debug/tracing/available_filter_functions
>> + # cat ./available_filter_functions
>> Âput_prev_task_idle
>> Âkmem_cache_create
>> Âpick_next_task_rt
>> @@ -1552,12 +1561,12 @@ mutex_lock
>> ÂIf I am only interested in sys_nanosleep and hrtimer_interrupt:
>>
>> Â # echo sys_nanosleep hrtimer_interrupt \
>> - Â Â Â Â Â Â > /debug/tracing/set_ftrace_filter
>> - # echo ftrace > /debug/tracing/current_tracer
>> - # echo 1 > /debug/tracing/tracing_enabled
>> + Â Â Â Â Â Â > ./set_ftrace_filter
>> + # echo ftrace > ./current_tracer
>> + # echo 1 > ./tracing_enabled
>> Â # usleep 1
>> - # echo 0 > /debug/tracing/tracing_enabled
>> - # cat /debug/tracing/trace
>> + # echo 0 > ./tracing_enabled
>> + # cat ./trace
>> Â# tracer: ftrace
>> Â#
>> Â# Â Â Â Â Â TASK-PID Â CPU# Â ÂTIMESTAMP ÂFUNCTION
>> @@ -1568,7 +1577,7 @@ If I am only interested in sys_nanosleep and
>> hrtimer_interrupt:
>>
>> ÂTo see which functions are being traced, you can cat the file:
>>
>> - # cat /debug/tracing/set_ftrace_filter
>> + # cat ./set_ftrace_filter
>> Âhrtimer_interrupt
>> Âsys_nanosleep
>>
>> @@ -1588,7 +1597,7 @@ Note: It is better to use quotes to enclose the
>> wild cards,
>> Â Â Â Âotherwise the shell may expand the parameters into names
>> Â Â Â Âof files in the local directory.
>>
>> - # echo 'hrtimer_*' > /debug/tracing/set_ftrace_filter
>> + # echo 'hrtimer_*' > ./set_ftrace_filter
>>
>> ÂProduces:
>>
>> @@ -1609,7 +1618,7 @@ Produces:
>>
>> ÂNotice that we lost the sys_nanosleep.
>>
>> - # cat /debug/tracing/set_ftrace_filter
>> + # cat ./set_ftrace_filter
>> Âhrtimer_run_queues
>> Âhrtimer_run_pending
>> Âhrtimer_init
>> @@ -1635,17 +1644,17 @@ To append to the filters, use '>>'
>> ÂTo clear out a filter so that all functions will be recorded
>> Âagain:
>>
>> - # echo > /debug/tracing/set_ftrace_filter
>> - # cat /debug/tracing/set_ftrace_filter
>> + # echo > ./set_ftrace_filter
>> + # cat ./set_ftrace_filter
>> Â #
>>
>> ÂAgain, now we want to append.
>>
>> - # echo sys_nanosleep > /debug/tracing/set_ftrace_filter
>> - # cat /debug/tracing/set_ftrace_filter
>> + # echo sys_nanosleep > ./set_ftrace_filter
>> + # cat ./set_ftrace_filter
>> Âsys_nanosleep
>> - # echo 'hrtimer_*' >> /debug/tracing/set_ftrace_filter
>> - # cat /debug/tracing/set_ftrace_filter
>> + # echo 'hrtimer_*' >> ./set_ftrace_filter
>> + # cat ./set_ftrace_filter
>> Âhrtimer_run_queues
>> Âhrtimer_run_pending
>> Âhrtimer_init
>> @@ -1668,7 +1677,7 @@ hrtimer_init_sleeper
>> ÂThe set_ftrace_notrace prevents those functions from being
>> Âtraced.
>>
>> - # echo '*preempt*' '*lock*' > /debug/tracing/set_ftrace_notrace
>> + # echo '*preempt*' '*lock*' > ./set_ftrace_notrace
>>
>> ÂProduces:
>>
>> @@ -1758,13 +1767,13 @@ the effect on the tracing is different. Every read from
>> Âtrace_pipe is consumed. This means that subsequent reads will be
>> Âdifferent. The trace is live.
>>
>> - # echo function > /debug/tracing/current_tracer
>> - # cat /debug/tracing/trace_pipe > /tmp/trace.out &
>> + # echo function > ./current_tracer
>> + # cat ./trace_pipe > /tmp/trace.out &
>> Â[1] 4153
>> - # echo 1 > /debug/tracing/tracing_enabled
>> + # echo 1 > ./tracing_enabled
>> Â # usleep 1
>> - # echo 0 > /debug/tracing/tracing_enabled
>> - # cat /debug/tracing/trace
>> + # echo 0 > ./tracing_enabled
>> + # cat ./trace
>> Â# tracer: function
>> Â#
>> Â# Â Â Â Â Â TASK-PID Â CPU# Â ÂTIMESTAMP ÂFUNCTION
>> @@ -1800,7 +1809,7 @@ number listed is the number of entries that can
>> be recorded per
>> ÂCPU. To know the full size, multiply the number of possible CPUS
>> Âwith the number of entries.
>>
>> - # cat /debug/tracing/buffer_size_kb
>> + # cat ./buffer_size_kb
>> Â1408 (units kilobytes)
>>
>> ÂNote, to modify this, you must have tracing completely disabled.
>> @@ -1808,21 +1817,21 @@ To do that, echo "nop" into the current_tracer. If the
>> Âcurrent_tracer is not set to "nop", an EINVAL error will be
>> Âreturned.
>>
>> - # echo nop > /debug/tracing/current_tracer
>> - # echo 10000 > /debug/tracing/buffer_size_kb
>> - # cat /debug/tracing/buffer_size_kb
>> + # echo nop > ./current_tracer
>> + # echo 10000 > ./buffer_size_kb
>> + # cat ./buffer_size_kb
>> Â10000 (units kilobytes)
>>
>> ÂThe number of pages which will be allocated is limited to a
>> Âpercentage of available memory. Allocating too much will produce
>> Âan error.
>>
>> - # echo 1000000000000 > /debug/tracing/buffer_size_kb
>> + # echo 1000000000000 > ./buffer_size_kb
>> Â-bash: echo: write error: Cannot allocate memory
>> - # cat /debug/tracing/buffer_size_kb
>> + # cat ./buffer_size_kb
>> Â85
>>
>> Â---
>>
>> On Sat, May 30, 2009 at 1:48 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>> >
>> >
>> >
>> > On Sat, 30 May 2009, GeunSik Lim wrote:
>> >
>> >>
>> >>
>> >> Dear Greg and Steen,
>> >>
>> >> Thanks your advices and opinions about a confusion according to
>> >> too many mount directory names for debugfs. I made rfc v2 patch file again like belows.
>> >> Can I hear your advices about below patch contents?.
>> >>
>> >> * ref:
>> >> http://groups.google.com/group/linux.kernel/browse_thread/thread/c34e386587979340/dc52317f888e78b6?#dc52317f888e78b6
>> >>
>> >>
>> >> Regards,
>> >> GeunSik Lim.
>> >>
>> >> Subject: [PATCH] Â Fix terminology inconsistency of dir name to mount debugfs filesystem.
>> >>
>> >> Â Â Â Many developers use "/debug/" or "/debugfs/ directory name to mount
>> >> Â Â Â debugfs filesystem for ftrace according to
>> >> Â Â Â ./Documentation/tracers/ftrace.txt file.
>> >>
>> >> Â Â Â And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
>> >> Â Â Â existed in kernel source like ftrace, DRM, Wireless, Network[sky2]files
>> >> Â Â Â to mount debugfs filesystem.
>> >>
>> >> Â Â Â debugfs means debug filesystem for debugging easy to use by greg kroah
>> >> Â Â Â hartman. "/sys/kernel/debug/" name is suitable as directory name
>> >> Â Â Â of debugfs filesystem.
>> >> Â Â Â -debugfs related reference: http://lwn.net/Articles/115405/
>> >
>> > Note, LWN has an update this week:
>> >
>> > Âhttp://lwn.net/Articles/334546/
>> >
>> > But it currently is subscriber only. Others would need to either buy a
>> > subscription (plug) or wait a week for it to become open.
>> >
>> > Still for some aspects, just having "debugfs" without the leading "/"
>> > might just be self explanatory. We can assume the user already knows where
>> > debugfs is mounted.
>> >
>> > -- Steve
>> >
>> >
>> >>
>> >> Â Â Â Fix inconsistency of directory name to mount debugfs filesystem.
>> >>
>> >> Â Â Â Â ÂSigned-off-by: GeunSik Lim <geunsik.lim@xxxxxxxxxxx>
>> >> Â Â Â Â ÂAcked-By: Inaky Perez-Gonzalez <inaky@xxxxxxxxxxxxxxx>
>> >> Â Â Â Â ÂCC: Greg KH <greg@xxxxxxxxx>
>> >> Â Â Â Â ÂCC: Steven Rostedt <rostedt@xxxxxxxxxxx>
>> >> Â Â Â Â ÂCC: linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>
>> >
>>
>>
>>
>> --
>> Regards,
>> GeunSik Lim ( SAMSUNG ELECTRONICS)
>> Blog : http://blog.naver.com/invain/
>> e-Mail: geunsik.lim@xxxxxxxxxxx
>> Â Â Â Â Â Âleemgs@xxxxxxxxx , leemgs1@xxxxxxxxx
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at Âhttp://www.tux.org/lkml/
>>



--
Regards,
GeunSik Lim ( SAMSUNG ELECTRONICS)
Blog : http://blog.naver.com/invain/
e-Mail: geunsik.lim@xxxxxxxxxxx
leemgs@xxxxxxxxx , leemgs1@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/