Reputation: 929
I would like to get the physical address of Linux "jiffies" variable so that I can read it by just reading the contents of this memory address.
Upvotes: 0
Views: 3498
Reputation: 2144
This is not directly related to your question but might still be relevant. I maintain a small project (devmem-rw) here: http://code.google.com/p/device-memory-readwrite/
It's quite useful to driver/kernel developers/testers; it lets one setup to be able to read/write any valid memory location- this could be RAM (user/kernel space), memory-mapped register locations, shared memory regions, etc.
Pl see the wiki area of the project (specifically, http://code.google.com/p/device-memory-readwrite/wiki/UsageWithExamples).
More relevant to your question, I use this project to demo a few use cases, one of them being repeated reads on the 'jiffies' value. Seeing that it changes proves the point..
From http://code.google.com/p/device-memory-readwrite/wiki/UsageWithExamples :
"... Eg. 2: Reading the value of 'jiffies' on an x86 PC The 'vm_img' kernel module mentioned earlier, also shows us the location of the 'jiffies_64' kernel global variable (which holds the current jiffies value); in the above run, it's kernel location turns out to be 0xc07c7a40. So:
# ./rdmem 0xc07c7a40 ; sleep 1; ./rdmem 0xc07c7a40 ; sleep 1; ./rdmem 0xc07c7a40
+0 +4 +8 +c 0 4 8 c
+0000 00 1a bc 20 ...
+0 +4 +8 +c 0 4 8 c
+0000 00 1a bd 23 ...#
+0 +4 +8 +c 0 4 8 c
+0000 00 1a be 1f ....
#
We can see how it's updated...(in fact, CONFIG_HZ=250 on this system, and some + factor is expected as well...). ... "
Pl see the project page for details. It's been found to be quite useful for driver developers- for eg they can probe/change register values without writing code :) Do give it a spin!
Upvotes: 2
Reputation: 10435
I think what you want is to access jiffies values from userspace.
You can write a small module that expose the jiffies
variable to a proc file.
Upvotes: 0
Reputation: 86443
From kernel-mode code (e.g. a loadable kernel module) you need to include the <linux/jiffies.h>
header file. It contains the definition of the jiffies
variable:
extern unsigned long volatile __jiffy_data jiffies;
However, it also contains this warning:
/*
* The 64-bit value is not atomic - you MUST NOT read it
* without sampling the sequence number in xtime_lock.
* get_jiffies_64() will do this for you as appropriate.
*/
I.e. you should not access this variable directly. It's a 64-bit variable and accesses to it are not atomic on 32-bit systems, hence the get_jiffies_64()
function from the same header file. On 64-bit systems that function is a very simple inline function that returns the value of the jiffies
variable.
From userspace code, on the other hand, you cannot access kernel memory at all.
Upvotes: 4
Reputation: 6081
When you reference jiffies
from kernel code, that's exactly what happens. What do you think needs improving in normal usage? If you need the address just use &jiffies
.
Upvotes: 0
Reputation: 36269
If you have the sources installed,
locate jiffies
schould reveal the .c and .h files, as in:
/usr/src/linux-headers-$(uname -r)/include/linux/jiffies.h
Upvotes: 0
Reputation: 206929
For kernel code, use the functions defined in include/linux/jiffies.h
. (get_jiffies_64
for example).
Kernel command using Linux system calls illustrates syscall handling in Linux with a userspace syscall that reads jiffies. Could be what you're after.
Linux obtain current of jiffies since reboot over at superuser also has some information you could be interested in.
Converting jiffies to milli seconds is also something to keep in mind.
Upvotes: 2