On 23 January 2014 15:06, Victor Kamensky <victor.kamensky@xxxxxxxxxx> wrote:
> In [1] I wrote
>
> "I don't see why you so attached to desire to describe
> data part of memory transaction as just one of int
> types. If we are talking about bunch of hypothetical
> cases imagine such bus that allow transaction with
> size of 6 bytes. How do you describe such data in
> your ints speak? What endianity you can assign to
> sequence of 6 bytes? While note that description of
> such transaction as set of 6 byte values at address
> $whatever makes perfect sense."
>
> But notice that in your next reply [2] you just dropped it
Yes. This is because it was one of the places where
I would have just had to repeat "no, I'm afraid you're wrong
about how hardware works". I think in general it's going
to be better if I don't try to reply point by point to this
email; I think you should go back and reread the emails I've
sent. Key points:
(1) hardware is not doing anything involving arrays
of bytes
(2) the API between kernel and userspace needs to define
the semantics of mmio.data, ie how to map between
"x byte wide transaction with value v" and the array,
and that is primarily what this conversation is about
(3) the only choice which is both (a) sensible and (b)
not breaking existing usage is to say "the array is
in host-kernel-byte-order"
(4) PPC CPUs in BE mode and ARM CPUs in BE mode are not
the same, because in the ARM case it is doing an
internal-to-CPU byteswap, and in the PPC case it is not
thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
