Arjan van de Ven wrote:
>
> It could be argued that gcc's implementation of volatile is wrong, and
> that gcc should add the appropriate serializing instructions before and
> after volatile accesses.
>
> Of course, that would make volatile even more suboptimal, but at least
> correct.
with PCI, and the PCI posting rules, there is no "one" serializing
instruction, you need to know the specifics of the device in question to
cause the flush. So at least there is no universal possible
implementation of volatile as you suggest ;-)
A serializing volatile makes it possible to write portable code to
access pci mmio. You'd just follow a write with a read or whatever the
rules say.
Of course, it would still generate horrible code, and would still be
unable to express notions like atomic accesses, so there is not much
point in it.
One point which was raised, is that optimization barriers also somewhat
pessimize the code. I wonder how useful a partial memory clobber could be:
#define spin_lock_data(lock, lock_protected_data...) \
do { __spin_lock(lock); asm volatile ( "" : : :
"memory"(lock_protected_data) ); } while(0)
Where __spin_lock has a partial memory clobber only on the lock variable
itself.
It would take a lot of work, but it can eliminate the instructions to
save and reload registers.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
