Re: 2.6.6-mm5

[ebiederm@xmission.com (Eric W. Biederman)]

Matt Mackall <mpm@selenic.com> writes:

> On Sat, May 22, 2004 at 06:15:51PM -0700, Roland Dreier wrote:
> >     Andrew> I don't think we can expect all architectures to be able
> >     Andrew> to implement atomic 64-bit IO's, can we?
> > 
> >     Andrew> ergo, drivers which want to use readq and writeq should
> >     Andrew> provide the appropriate locking.
> > 
> > Perhaps we should have ARCH_HAS_ATOMIC_WRITEQ or something so that
> > drivers don't add the overhead of locking on architectures where it's
> > not necessary?
> 
> Or perhaps we just need a lockless __readq/__writeq for drivers that
> know better.

I can see implementing these emulations with a name of
readq_emulated/writeq_emulated, or readl2/writel2.  For drivers that
can stand not generating a true 64bit bus I/O cycle to the device,
that sounds helpful.

However there are and will likely continue to be devices that need a
64bit I/O cycle on the bus.  That is what writeq logically/obviously
does.  Putting an emulation in place of the real thing is likely to
cause all sorts subtle of problems. 

Having listened to this conversation for a while I strongly dislike
the atomic language because that sounds like generating the wrong bus
cycles are somehow OK, and doing what the function says it does is
somehow just an optimization.

If no hardware actually cared or someone could show me that you can't
generate a 64bit memory I/O cycle on the PCI bus that would be
interesting.  I have seen several drivers that care.  Later today
I intend to look at my pci docs and confirm that 64bit I/O cycles
do exist on the bus, even in 32bit slots.  PCI bus traffic is packet
based so I would be strongly surprised if 64bit cycles did not
exist.

Eric