On 06/06/2012 02:12 PM, Anthony Liguori wrote: > On 06/06/2012 05:58 PM, Avi Kivity wrote: >> On 06/06/2012 12:17 PM, Anthony Liguori wrote: >>>> >>>> So, is it reasonable to say >>>> >>>> uint32_t * _immutable irrp; // Interrupt Request Register >>>> >>>> and allocate it on the heap during initialization? >>> >>> No, this would be wrong. >>> >>> '_immutable' means that the *state* is immutable from the guests point >>> of view. The state stored by: >>> >>> struct MyDevice { >>> Backend _immutable *backend; >>> } >>> >>> Is the *reference* to the backend. The state of the backend is not part >>> of the device's state structure. Only the *reference* to the backend is >>> part of the device's state and that's immutable. >> >> I think this has degenerated into a disagreement about naming. Yet I >> think this is important. I don't think _immutable suggests "immutable >> from the guest's point of view" or even "we assume shared storage [1], >> therefore it's immutable" to a device model author or reviewer. I think >> we should choose the names under the assumption that the author did not >> read the documentation (why bother when you can copy paste another >> device model implementation) or read it and immediately forgot it. This >> goes double for the reviewer(s). We need to make this as unsubtle as >> possible (but no unsubtler). > > Okay, we're talking past each other then. > > I'm not really taking a position on the best naming convention to use > for these things. This is too early of a patch series. Whether we > should have multiple variants of '_immutable' that make it easier for > reviewers is something that I'm 100% open too. > > But I think it's important to have a strong conceptional model. So far, > it's built on the following: > > All device state is serialized unless: > > a) It's derived from other state > > b) It's immutable (from the guest PoV)
I'm harping again on naming, but using _immutable to mean _immutable_from_the_guest_point_of_view is confusing. _immutable means _immutable. I don't think people will be able to answer "is this immutable from a guest point of view" easily. > > c) We should migrate it but don't know and don't immediately want to > change that d) the RAM migration code takes care of migrating it e) the block layer takes care of migrating it > If we want to subdivide (b) into a set of more specific things, that's > perfectly fine by me. But I'm reluctant to just add a "(d) it's host > state" because it breaks my mental model. Suppose you save/restore a guest that is connected to a host cdrom. The cdrom tray state (and indeed the cdrom data) should not be save/restored, because you want the real (host) data to be used after restore. The same is true for a serial device that is connected to a host serial device and reads line state from it. > >> >>> If you think the syntax is confusing, then once you find a time machine, >>> I'll happily travel with you 40 years into the past and we can try to >>> convince K&R to introduce a richer pointer syntax that allows for >>> differentiating between various use-cases of pointers. >> >> A go port of qemu would be interesting. > > Perhaps in 10 years. I think go is a little too immature right now. > Submit your talks now for KVM Forum 2022 ;-) In 10 years go would be old and crusty and I'd be drumming for the hot new language of the day. -- error compiling committee.c: too many arguments to function