local_t Documentation update 2
(this patch seems to have fallen off the grid, but is still providing
useful information. It applies to 2.6.23-mm1.)
Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to local_ops.txt.
On Wed, Aug 29, 2007 at 08:19:53AM -0400, Mathieu Desnoyers wrote:
> local_t Documentation update 2
>
> Grant Grundler was asking for more detail about correct usage of local atomic
> operations and suggested adding the resulting summary to local_ops.txt.
>
> "Please add a bit more detail. If Dav
local_t Documentation update 2
Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to local_ops.txt.
"Please add a bit more detail. If DaveM is correct (he normally is), then
there must be limits on how the local_t ca
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> > So it is "one cpu may write, other cpus may read", and as big as
> > long. Are you sure obscure architectures (sparc?) can implement this
> > in useful way? ... maybe yes, unless obscure architecture exists where
> > second other cpu can see garbag
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> > index dfeec94..bd854b3 100644
> > --- a/Documentation/local_ops.txt
> > +++ b/Documentation/local_ops.txt
> > @@ -22,6 +22,13 @@ require disabling interrupts to protect from interrupt
> > handlers and it permits
> > coherent counters in NMI handlers.
Hi!
> > AFAICT this fails to mention... Is local_t as big as int? As big as
> > long? Or perhaps smaller because high bits may be needed for locking?
>
> Hi Pavel,
>
> Here is an update that adds the information you mentionned in this reply and
> the
> one to Andrew. Thanks for the comments.
>
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> Hi!
>
> AFAICT this fails to mention... Is local_t as big as int? As big as
> long? Or perhaps smaller because high bits may be needed for locking?
>
> Pavel
>
Hi Pavel,
Here is an
7 matches
Mail list logo
