volatile: revert changes introduced by #95

[jiangliu]

95 fixed the problem of torn reads/writes caused by the implementation

of read/write_obj essentially leveraging the environment specific memcpy, and the implicit assumption that read/write_obj perform atomic accesses up to a certain size at aligned addresses. Meanwhile, we added the load/store operations to Bytes which provide explicit atomic access semantics.

Now there are three possible types of memory access methods: 1) atomic access: VolatileSlice::load/store() for integer atomic data types 2) volatile access: {VolatileRef|VolatileArrayRef}::{load|store()| copy_from|copy_from} when size_of::() > 1 3) normal access: all other byte stream oriented memory accesses

Explicitly states that GuestMemory/Bytes are byte stream oriented, and do not guarantee atomicity. Callers need to be care to choose the access method, in preference for both safety and high performance.

Signed-off-by: Liu Jiang gerry@linux.alibaba.com

Fixes: #95

[alexandruag]

As we mentioned in #123, this may have more profound implications on the consumers of vm-memory. Is it ok if we try to merge and release the other active PRs first, and then circle back to this one and release it as well?