On Fri, Oct 12, 2012 at 08:21:50PM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" <m...@redhat.com> writes: > > On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote: > >> >> For writes, the standard seems to be a commit latch. We could abuse the > >> >> generation count for this: the driver writes to it to commit config > >> >> changes. > >> > > >> > I think this will work. There are a couple of things that bother me: > >> > > >> > This assumes read accesses have no side effects, and these are sometimes > >> > handy. > >> > Also the semantics for write aren't very clear to me. > >> > I guess device must buffer data until generation count write? > >> > This assumes the device has a buffer to store writes, > >> > and it must track each byte written. I kind of dislike this > >> > tracking of accessed bytes. Also, device would need to resolve conflicts > >> > if any in some device specific way. > >> > >> It should be trivial to implement: you keep a scratch copy of the config > >> space, and copy it to the master copy when they hit the latch. > >> > >> Implementation of this will show whether I've missed anything here, I > >> think. > > > > What I refer to: what happens if driver does: > > - write offset 1 > > - write offset 3 > > - hit commit latch > > - nothing > - nothing > - effect of offset 1 and offset 3 writes
OK so this means that you also need to track which bytes where written in order to know to skip byte 2. This is what I referred to. If instead we ask driver to specify offset/length explicitly device only needs to remember that. Not a big deal anyway, just pointing this out. > Now, since there's nothing published by the *driver* at the moment > which can't be trivially atomically written, this scheme is overkill > (sure, it means you could do a byte-at-a-time write to some 4-byte > field, but why?). > > But perhaps it's overkill: no other bus has this feature, so we'd need a > feature bit for them anyway in future if we create a device which needs > such atomicity. > > Cheers, > Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
