[PATCH] give explicit guidance on the use of 64 bit fields

From
James Bottomley <>
Date
2015-04-12T16:34:00+00:00
ID
Thread
[PATCH] give explicit guidance on the use of 64 bit fields
On Sun, 2015-04-12 at 18:22 +0200, Michael S. Tsirkin wrote:
> On Sun, Apr 12, 2015 at 04:06:28PM +0000, James Bottomley wrote:
>
> Just saying 64 bit fields may not be atomic is true, but less helpful
>
> than it might be.  Add explicit guidance about what the consequences of
>
> non-atomicity are
> >
>
> Signed-off-by: James Bottomley <>
> >
> > ---
>
> diff --git a/newdevice.tex b/newdevice.tex
>
> index c7e6221..12123b9 100644
> > --- a/newdevice.tex
> > +++ b/newdevice.tex
> > @@ -24,6 +24,8 @@ large).
> >
>
>  Remember that configuration fields over 32 bits wide might not be
>
>  atomically writable by the driver.
> > +Therefore, no writeable field which triggers an action should be wider than 32
> > +bits.
> >
> >  \section{What Device Number?}\label{sec:Creating New Device Types / What Device Number?}
> >
> >
> >
>
>
> It's best to avoid the word "should" outside normative statements.
> Can you rephrase this?

I've got to say that's a bit daft: should is the standard verbal
modifier for conditional or subjunctive ... it's quite a big chunk of
the english language.

However, to be honest, I think the statement needs to be normative.
It's not advisory: if someone creates a 64 bit action field the spec
becomes invalid on 32 bit architectures.

The only valid reason to ignore the statement is if your action field
has a specifically defined trigger (like only 32 bit writes to the lower
field triggers the action, so you write upper first then lower).  That's
why I think it's "should" rather than "may not".

James

James