Re: 2.6.7-rc1-mm1

[Eric W. Biederman]

Andrew Morton <akpm@xxxxxxxx> writes:

> add-i386-readq.patch
>   add i386 readq()/writeq()

- Again this is logically broken.

  On 32bit-PCI bursts (the basic unit of transfer) can be split and
  merged on 32bit boundaries so you can't be atomic on the bus.  But
  note even if a  64bit transaction is split (which is unlikely) the
  order of the operations on the device will remain the same because
  of pci ordering rules.

  On 64bit-PCI bursts can only be split on 64bit boundaries so there
  are 64bit atomic cycles on the bus.

  In PCI-X bursts can only be split when the address is a multiple
  of 128.  So cards can care about atomic 64bit cycles.

  In PCI-E switches do not touch the packets and devices are explicitly
  allowed to reject any packet they don't like.

So a readq or a writeq can on existing hardware be detected, and cared
about.

The strongest argument that this readq/writeq is broken
is this chunk of the hpet patch.

+#if BITS_PER_LONG == 64
+#define        write_counter(V, MC)    writeq(V, MC)
+#define        read_counter(MC)        readq(MC)
+#else
+#define        write_counter(V, MC)    writel(V, MC)
+#define        read_counter(MC)        readl(MC)
+#endif

The code still cares and does not trust the readq/writeq emulations
to do the same thing as their atomic counter parts.

So would a patch that names those helper functions readl2 and writel2
be acceptable?  Just so it is clear what they do?

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/