> Another solution is to change the <asm/bitops.h> to work with
> non-word-aligned locks.
>
> Heads up, take a look at other places within the kernel where objects
> are used by bitops, they are all defined in such a way as to be word
> aligned. This is not only a semantic issue, it is also a
> performance/capability issue. [ I had to fix this in various places
> at one point, linux/mm.h:mem_map_t->flags was one example ]
>
> At least on the Alpha and Sparc64 processors, the atomic instructions
> with which the bitops must be implemented, only allow word aligned
> datums to be used.
That's fine, and I do understand those architectures.. but it's not a
semantic issue.
Look at the Alpha code for test_and_set_bit().
It supports bit offsets greater than the word length.
It isn't noticably more difficult to take the byte address into
account when doing this calculation. It's *not* a word vs. byte operation
issue.
You can do whole-word operations either way.
> So most of us would prefer that your driver defines bitop objects to
> be word aligned thanks ;-)
My drivers do, because I have complete control over that code.
But not all fields in struct device are word aligned.
The issue is using dev->interrupt as an atomic lock. It's a field that
didn't originally need to an atomic lock. (It is now a lock to work around
what I claim is a bug in SMP interrupt dispatch -- the same interrupt
handler is called simultaneously on multiple processors.)
I'm working around the problem by having my own word-aligned locks, but this
issue will come up again.
My point is that the current bitop semantics could be easily fixed.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html