Pavel Machek wrote:
On Sat 2009-01-03 20:30:44, Alan Cox wrote:
If it is okay and linux relies on it, it should be documented.
If it is not okay, I guess we should document it, too -- it seems to
be common mistake.
A lot of old code did it knowing it was under the BKL, outside of the BKL
its a very bad idea. There were lots of them in the tty layer and I don't
doubt there are some left I missed too 8(
I have seen this in new code (some LED driver last time), definitely
no BKL.
Is there concrete architecture where it breaks? I'd expect i386/x86-64
to be safe, and pretty much everyone to be safe as long as that long
is aligned.... or that was the result of arch-maintainers
discussion...
I'd really like to document if it is right or not, so that I can point
people to documentation...
Pavel
If you look at the atomic implementation on x86 all it does is assign
and read the internal int variable directly for atomic_set and
atomic_read, so I suppose it would be OK to just use a normal variable
in that case.. but then there's no performance hit so you might as well
use atomic_t anyway. On some architectures like arm and sparc there is
some magic involved in atomic_set and/or atomic_read (but those may just
be to guard against other concurrent atomic ops, I'm not sure).
Certainly unless the code is really performance critical there is no
point messing around, just use an atomic if it needs to be accessed
without locking. Note that memory barriers may be an issue as well..
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
