Re: [libvirt] [PATCHv3 00/13] Add new PCIe controllers

On 08/03/2015 08:33 AM, John Ferlan wrote: I've had problems in the past when I made the assumption that two apparently mutually exclusive things could share the same space. One day you get to a place where that isn't true, then you're screwed. Kind of like when you're time traveling and see a former/future version of yourself, and then time-space asplodes and there's no big sloppy mess to clean up because the universe has collapsed into a black hole or something... Kind of. I don't get this one - the comparison is on the entire string, not on a prefix of the string, so there can be no confusion. The whole point of auto-setting it in the xml is to assure that it will never change "by accident" in the future. If we imply some value when it isn't explicitly set in the xml, then at some later date decide to change how we derive the implicit value, then we will have broken ABI of the guest (albeit in a probably inconsequential way, since my understanding is that essentially nobody uses these values :-/), and we don't want to do that. Well, there are two conflicting situations we want to avoid: 1) having the chassisNr changed in the guest because libvirt internally changed the way it implicitly arrived at the value to use for chassisNr, and 2) having the chassisNr be in conflict with the chassisNr of some other pci controller because the user modified their config by both changing the index of this controller *and* adding a new controller of the same type/model in the old index. The possibility of either is, quite frankly, rather remote. But in case (1) this "something bad" would happen with no conscious action on the part of the user (other than upgrading libvirt), so if it caused problems it would confuse/confound them. In case (2), at least it would be happening after they messed with the config (in a manner that almost nobody will ever do), so they might at least have some kind of clue what caused the problem. Note that what we're doing here follows exactly the same behavior that we follow with network device model types - if no model type is given when the interface is added to the domain, rlt8139 is automatically added. We used to just leave it empty and set it to "whatever was qemu's default", but decided this was too dangerous - we really need to spell out every last detail in the XML and not rely on defaults, otherwise we run into problems when we want to change the defaults. That would be nullifying the entire purpose of storing chassisNr. Derp. Yeah, that must have snuck in during one of the dozens of rebases. I removed the one that incorrectly checked chassisNr, of course.