Re: set_super_anon in fs/super.c
Look inline for comments. On Tue, Oct 23, 2012 at 7:30 PM, Abhijit Chandrakant Pawar abhi.c.pa...@gmail.com wrote: ** Hi Rohan, On Tue, 2012-10-23 at 18:47 +0530, Rohan Puri wrote: On Tue, Oct 23, 2012 at 6:33 PM, Abhijit Chandrakant Pawar abhi.c.pa...@gmail.com wrote: I am working on the layered file systems. I came across a function called set_super_anon. This is a callback to the sget function to compare the superblock . This function accepts two parameters. first is superblock * and second is void *. If you look at the definition of this function, the void* is never used. Many filesystem uses this function when they are mounting the superblock. Some pass NULL and some pass actual data.I have looked till 2.6.31 but there isnt any trace of the usage of second parameter. If it is never used then why its added to the function param list? Is there any historical reason during the older kernel days? Regards, Abhijit Pawar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Hi Abhijit, See the issue is this function is passed as an argument to sget(), now their are many other file-systems that defined their own set_super function for that they need data argument where they usually pass mount-related data For eg. see the definition and usage of function nfs_set_super(). So, the prototype of the sget() should contain function ptr (set_super()) and this function ptr should have data argument also. Now one usage can imply NO USE of the data parameter, which is set_super_anon, but other file-systems may require, so the sget() prototype should be generic to support, both the cases. Yes... thats what I thought. many are passing data un-necessarily to this function wherein they already have captured the required information for their purpose in their own defined function. Do you mean to say, each fs's own set_super function makes a call to set_anon_super() with data parameter as their specific data, but set_anon_super makes no use of it? Wouldnt that cause stack to store the value un-necessarily? It would be good if everybody passes NULL as second param. Yes, each fs's set_super, if makes a call to anon_super() should pass NULL as the second parameter(void *data) since anon_super doesnt make use of this parameter, need for this parameter just arises to match the prototype of sget()'s function ptr agrument. Also do remember the pointer to this data is passed, so only a word-size of extra stack is utilized when a call to this function is made. - Rohan - Rohan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
About effective resolution of cpu execution clocks
Dear all, I resend this question that I posted yesterday in the Linux Real-Time mailing list but received no answers maybe due to its newbie status. http://marc.info/?l=linux-rt-usersm=135099100016609w=2 let me rephrase-it for a generic not necessary real-time aware audience: The question concerns the per-process CPU usage statistics maintained by the kernel. As far as I can tell, the only places where this usage counter is stored are in the utime and stime fields of task_struct. http://lxr.linux.no/#linux+v3.6.3/include/linux/sched.h#L1362 (line 1362) I have observed that these fields are of type cputime_t which seems to be defined as an unsigned long and therefore contain 32bits (at least in a 32bit architecture such as x86). http://lxr.linux.no/linux+v3.6.3/include/asm-generic/cputime.h#L7 These fields utime and stime are used as accumulators of time usage in the implementation of POSIX CPU-usage clocks and timers. http://lxr.linux.no/#linux+v3.6.3/kernel/posix-cpu-timers.c A typical use-case of this functionality is measuring the CPU time consumed by a thread. In real-time systems this information can be used for further actions such as changing its priority, sending a signal or whatever. Here is an example using NPTL from libc: clockid_t clock; struct timespec before_ts, after_ts, interval; pthread_getcpuclockid( pthread_self(), clock ); clock_gettime(clock, before_ts); ... do your things here clock_gettime(clock, after_ts); interval = timespec_substract(after_ts, before_ts); In this code the time is stored in a struct timespec which is composed of 2 32-bit longs obtaining both a resolution of nanoseconds and a expand of years. On the other side 32bit integers such as utime and stime cannot provide both a high resolution and high time span. And according to the man page of proc, when these fields are output from /proc/pid/stat they give the value in jiffies (1/CONFIG_HZ sg, i.e. 4 millisec in most kernel configs). The way clock_gettime works, when linked to a process CPU clock is by keeping a counter of CPU usage updated by the scheduler on every preemption action + using hardware facilities to measure the latest time period. I assume that Linux, specially since the merge of high resolution timers in 2.6.21, benefits now from the latest hardware facilities for time management gaining resolutions of micro and nanoseconds, as reported by clock_getres(). With this background in mind I repeat the same questions that I asked in the linux-rt mailing list: * What is the effective resolution of two invocations of clock_gettime() on the same running thread for a long period involving several CPU preemptions? * Are there other fields apart from stime and utime with the sufficient precision to maintain a CPU usage count? * Does the PREEMPT_RT branch improve this resolution somehow? Thanks in advance for your time. Cheers, Miguel Telleria -- --- Miguel TELLERIA DE ESTEBANGrupo de computadores y tiempo real telleriam ENSAIMADA unican.es Dept. Electrónica y Computadores (change ENSAIMADA for @) Universidad de Cantabria http://www.ctr.unican.es Tel trabajo: +34 942 201477 --- signature.asc Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
yet another tutorial: where does all that stuff in /proc/interrupts come from?
dashed off in about an hour: http://www.crashcourse.ca/wiki/index.php/Proc_interrupts eventually, all these tutorials will be reorganized and will allow reader comments so you can give feedback and ask questions. enjoy. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
linux segment
Hi all: I print the cs ds and ss register in the user space, and it is same as the __USER_CS and __USER_DS which defined in kernel as 73 and 7b. In the kernel __KERNEL_CS and __KERNEL_DS defined as 60 and 68, but when I print this two value in my kernel module, I get 60 and 7b. Why ? It should be 60 and 68, shouldn't it? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Chekpatch does not warn about some quoted string split across lines
On Wed, Oct 24, 2012 at 12:01:16PM +0530, Anmol Sarma wrote:
I've noticed that that some quoted string split across lines are not
reported by checkpatch.pl. For example, running it on
/drivers/staging/android/binder.c does not warn of multi-line strings at
lines 512, 544, 776, 804 and several others. Does anyone know why this is
happening?
Thanks!
well, checkpatch.pl is a very helpful script but it is still a buggy one.
see below the part of the code (checkpatch.pl:1779) where split strings is
checked and warned:
START -
# Check for user-visible strings broken across lines, which breaks the ability
# to grep for the string. Limited to strings used as parameters (those
# following an open parenthesis), which almost completely eliminates false
# positives, as well as warning only once per parameter rather than once per
# line of the string. Make an exception when the previous string ends in a
# newline (multiple lines in one string constant) or \n\t (common in inline
# assembly to indent the instruction on the following line).
if ($line =~ /^\+\s*/
$prevline =~ /\s*$/
$prevline =~ /\(/
$prevrawline !~ /\\n(?:\\t)*\s*$/) {
WARN(SPLIT_STRING,
quoted string split across lines\n . $hereprev);
}
END ---
Now, let's analyze the conditions to trigger the warnning:
condition 1]
# True if the line with double quotes (we can have whitespaces before it)
$line =~ /^\+\s*/
condition 2]
# True if the previous line ends with a double quote (we can have
# whitespaces after it)
$prevline =~ /\s*$/
condition 3]
# True if the previous line has a open parenthesis (we are looking for
# strings as parameters only)
$prevline =~ /\(/
condition 4]
# True if the previous line don't have a multiple lines in one string
$prevrawline !~ /\\n(?:\\t)*\s*$/) {
WARN(SPLIT_STRING,
quoted string split across lines\n . $hereprev);
So, let's look at an example of the kind line which checkpatch.pl does not
trigger the warning when it should:
driver/staging/android/binder.c:544
SART --
binder_debug(BINDER_DEBUG_BUFFER_ALLOC,
binder: %d: add free buffer, size %zd,
at %p\n, proc-pid, new_buffer_size, new_buffer);
END ---
When checkpatch.pl reads the line 544 (the line which it should trgger the
warning) of binder.c and enters the split string check we have:
condition 1: matches, the third line of the code snippet, it ends with a ''
condition 2: matches, the previous line ends with a double quote
condition 3: NOT MATCH, the previous line does not have a open paranthesis
So the reason why checkpatch.pl does not trigger the warning on these lines is:
_the opening parenthesis is not on the previous line_, but on the line
before the previous line, and checkpatch does not foresee this particular case.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: set_super_anon in fs/super.c
On 10/24/2012 01:50 PM, Rohan Puri wrote: Look inline for comments. On Tue, Oct 23, 2012 at 7:30 PM, Abhijit Chandrakant Pawar abhi.c.pa...@gmail.com mailto:abhi.c.pa...@gmail.com wrote: Hi Rohan, On Tue, 2012-10-23 at 18:47 +0530, Rohan Puri wrote: On Tue, Oct 23, 2012 at 6:33 PM, Abhijit Chandrakant Pawar abhi.c.pa...@gmail.com mailto:abhi.c.pa...@gmail.com wrote: I am working on the layered file systems. I came across a function called set_super_anon. This is a callback to the sget function to compare the superblock . This function accepts two parameters. first is superblock * and second is void *. If you look at the definition of this function, the void* is never used. Many filesystem uses this function when they are mounting the superblock. Some pass NULL and some pass actual data.I have looked till 2.6.31 but there isnt any trace of the usage of second parameter. If it is never used then why its added to the function param list? Is there any historical reason during the older kernel days? Regards, Abhijit Pawar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org mailto:Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Hi Abhijit, See the issue is this function is passed as an argument to sget(), now their are many other file-systems that defined their own set_super function for that they need data argument where they usually pass mount-related data For eg. see the definition and usage of function nfs_set_super(). So, the prototype of the sget() should contain function ptr (set_super()) and this function ptr should have data argument also. Now one usage can imply NO USE of the data parameter, which is set_super_anon, but other file-systems may require, so the sget() prototype should be generic to support, both the cases. Yes... thats what I thought. many are passing data un-necessarily to this function wherein they already have captured the required information for their purpose in their own defined function. Do you mean to say, each fs's own set_super function makes a call to set_anon_super() with data parameter as their specific data, but set_anon_super makes no use of it? Wouldnt that cause stack to store the value un-necessarily? It would be good if everybody passes NULL as second param. Yes, each fs's set_super, if makes a call to anon_super() should pass NULL as the second parameter(void *data) since anon_super doesnt make use of this parameter, need for this parameter just arises to match the prototype of sget()'s function ptr agrument. Also do remember the pointer to this data is passed, so only a word-size of extra stack is utilized when a call to this function is made. I have made a patch for those filesystems and submitted to the kernel list. - Rohan - Rohan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: set_super_anon in fs/super.c
On Thu, Oct 25, 2012 at 9:40 AM, Abhijit Pawar abhi.c.pa...@gmail.comwrote: On 10/24/2012 01:50 PM, Rohan Puri wrote: Look inline for comments. On Tue, Oct 23, 2012 at 7:30 PM, Abhijit Chandrakant Pawar abhi.c.pa...@gmail.com wrote: Hi Rohan, On Tue, 2012-10-23 at 18:47 +0530, Rohan Puri wrote: On Tue, Oct 23, 2012 at 6:33 PM, Abhijit Chandrakant Pawar abhi.c.pa...@gmail.com wrote: I am working on the layered file systems. I came across a function called set_super_anon. This is a callback to the sget function to compare the superblock . This function accepts two parameters. first is superblock * and second is void *. If you look at the definition of this function, the void* is never used. Many filesystem uses this function when they are mounting the superblock. Some pass NULL and some pass actual data.I have looked till 2.6.31 but there isnt any trace of the usage of second parameter. If it is never used then why its added to the function param list? Is there any historical reason during the older kernel days? Regards, Abhijit Pawar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Hi Abhijit, See the issue is this function is passed as an argument to sget(), now their are many other file-systems that defined their own set_super function for that they need data argument where they usually pass mount-related data For eg. see the definition and usage of function nfs_set_super(). So, the prototype of the sget() should contain function ptr (set_super()) and this function ptr should have data argument also. Now one usage can imply NO USE of the data parameter, which is set_super_anon, but other file-systems may require, so the sget() prototype should be generic to support, both the cases. Yes... thats what I thought. many are passing data un-necessarily to this function wherein they already have captured the required information for their purpose in their own defined function. Do you mean to say, each fs's own set_super function makes a call to set_anon_super() with data parameter as their specific data, but set_anon_super makes no use of it? Wouldnt that cause stack to store the value un-necessarily? It would be good if everybody passes NULL as second param. Yes, each fs's set_super, if makes a call to anon_super() should pass NULL as the second parameter(void *data) since anon_super doesnt make use of this parameter, need for this parameter just arises to match the prototype of sget()'s function ptr agrument. Also do remember the pointer to this data is passed, so only a word-size of extra stack is utilized when a call to this function is made. I have made a patch for those filesystems and submitted to the kernel list. - Rohan - Rohan Cool :) - Rohan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
