Hi Manavendra,
Couple of things are involved in above experiment.
1. const
The variable "value" is defined as
- "static const int" in driver.c.
- "extern int" in hacker.c (i.e. not const).
2. volatile
An object marked volatile is always fetched from memory and the
compiler does NOT try to optimise away this read from memory. This is
because volatile is an explicit indication to the compiler to fetch
the value from memory and not used older value cached in CPU-register.
Here is whats happening in regular case:
driver.ko init()
- alloc RAM for "value"
- load value of "value" into register
- print "value"
(123 in driver.ko context)
hacker.ko init()
(no alloc RAM as it is extern. Allow assignment as its NOT const here).
- load value of "value" into register
- print "value"
(987 in hacker.ko context)
hacker.ko exit()
- print "value"
(987 in hacker.ko context)
driver.ko exit()
- print "value"
(123 in hacker.ko context)
Here is whats happening in case volatile is used:
driver.ko init()
- alloc RAM for "value"
- load value of "value" into register
- print "value"
(123 in driver.ko context)
hacker.ko init()
(no alloc RAM as it is extern. Allow assignment as its NOT const here).
- load value of "value" into register
- print "value"
(987 in hacker.ko context)
hacker.ko exit()
- print "value"
(987 in hacker.ko context)
driver.ko exit()
- fetch value of "value" from RAM.
(as volatile forces an explicit read from memory)
- print "value"
(987 copied from hacker.ko context into driver.ko context)
As Alan mentioed above, it will be interesting to look into the
assembly code of your modules. Run objdump -S on your .ko modules and
search for .init.text and .exit.text in the assembly. Observing where
the compiler decides to place the object "value" should explain why
things work the way they do.
--
regards
CVS
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
