[LOCK] Is it really necessary to use a "big module lock"?

Hi all, I came across a question when review other's module code. something like: int __init module_init() { down_interruptible(the_big_module_sem); // code for init... up(the_big_module_sem); } void __exit module_exit() {

[LOCK] Is it really necessary to use a big module lock?

Hi all, I came across a question when review other's module code. something like: int __init module_init() { down_interruptible(the_big_module_sem); // code for init... up(the_big_module_sem); } void __exit module_exit() {

Re: [PATCH] make atomic_t volatile on all architectures

On Thu, 09 Aug 2007 11:10:16 +0200 Bodo Eggert <[EMAIL PROTECTED]> wrote: > > > > Why the *volatile-accesses-in-code* is acceptable, does C standard make it > > clear? > > http://lwn.net/Articles/233482/ I have read this article before, but What Linus said only focusing on the conclusion-- The

Re: [PATCH] make atomic_t volatile on all architectures

On Thu, 09 Aug 2007 11:10:16 +0200 Bodo Eggert [EMAIL PROTECTED] wrote: Why the *volatile-accesses-in-code* is acceptable, does C standard make it clear? http://lwn.net/Articles/233482/ I have read this article before, but What Linus said only focusing on the conclusion-- The semantics

Re: [PATCH] make atomic_t volatile on all architectures

On Wed, 8 Aug 2007 21:18:25 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Wed, 8 Aug 2007, Chris Snook wrote: > > > > Some architectures currently do not declare the contents of an atomic_t to > > be > > volatile. This causes confusion since atomic_read() might not actually

Re: why are some atomic_t's not volatile, while most are?

On Wed, 08 Aug 2007 02:47:53 -0400 Chris Snook <[EMAIL PROTECTED]> wrote: > Chris Friesen wrote: > > Chris Snook wrote: > > > >> This is not a problem, since indirect references will cause the CPU to > >> fetch the data from memory/cache anyway. > > > > Isn't Zan's sample code (that shows the

Re: why are some atomic_t's not volatile, while most are?

On Wed, 08 Aug 2007 02:47:53 -0400 Chris Snook <[EMAIL PROTECTED]> wrote: > Chris Friesen wrote: > > Chris Snook wrote: > > > >> This is not a problem, since indirect references will cause the CPU to > >> fetch the data from memory/cache anyway. > > > > Isn't Zan's sample code (that shows the

Re: why are some atomic_t's not volatile, while most are?

On Wed, 08 Aug 2007 02:47:53 -0400 Chris Snook [EMAIL PROTECTED] wrote: Chris Friesen wrote: Chris Snook wrote: This is not a problem, since indirect references will cause the CPU to fetch the data from memory/cache anyway. Isn't Zan's sample code (that shows the problem) already

Re: why are some atomic_t's not volatile, while most are?

On Wed, 08 Aug 2007 02:47:53 -0400 Chris Snook [EMAIL PROTECTED] wrote: Chris Friesen wrote: Chris Snook wrote: This is not a problem, since indirect references will cause the CPU to fetch the data from memory/cache anyway. Isn't Zan's sample code (that shows the problem) already

Re: [PATCH] make atomic_t volatile on all architectures

On Wed, 8 Aug 2007 21:18:25 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: On Wed, 8 Aug 2007, Chris Snook wrote: Some architectures currently do not declare the contents of an atomic_t to be volatile. This causes confusion since atomic_read() might not actually read

Re: why are some atomic_t's not volatile, while most are?

On Tue, 07 Aug 2007 16:32:23 -0400 Chris Snook <[EMAIL PROTECTED]> wrote: > > It seems like this would fall more into the case of the arch providing > > guarantees when using locked/atomic access rather than anything > > SMP-related, no?. > > But if you're not using SMP, the only way you get a

Re: why are some atomic_t's not volatile, while most are?

On Tue, 07 Aug 2007 16:32:23 -0400 Chris Snook [EMAIL PROTECTED] wrote: It seems like this would fall more into the case of the arch providing guarantees when using locked/atomic access rather than anything SMP-related, no?. But if you're not using SMP, the only way you get a race

Re: why are some atomic_t's not volatile, while most are?

Is there some feedback on this point ? Thank you ./Jerry On Sun, 1 Jul 2007 08:49:37 -0400 (EDT) "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > > prompted by the earlier post on "volatile"s, is there a reason that > most atomic_t typedefs use volatile int's, while the rest don't? > > $

Re: why are some atomic_t's not volatile, while most are?

Is there some feedback on this point ? Thank you ./Jerry On Sun, 1 Jul 2007 08:49:37 -0400 (EDT) Robert P. J. Day [EMAIL PROTECTED] wrote: prompted by the earlier post on volatiles, is there a reason that most atomic_t typedefs use volatile int's, while the rest don't? $ grep

Google Earth displays improperly - 2.6.20-rc6

When I update my kernel to 2.6.20-rc6, I find I can not move the map smoothly in the Google Earth (V4). I do not try any test on this issue. just put it to maillist. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More

Google Earth displays improperly - 2.6.20-rc6

When I update my kernel to 2.6.20-rc6, I find I can not move the map smoothly in the Google Earth (V4). I do not try any test on this issue. just put it to maillist. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More