Cc: David for insurance against me spewing nonsense about migration. John Snow <js...@redhat.com> writes:
> On 6/25/20 12:45 AM, Markus Armbruster wrote: >> John Snow <js...@redhat.com> writes: >> >>> On 6/22/20 5:42 AM, Markus Armbruster wrote: >>>> There are three ways to configure backends: >>>> >>>> * -nic, -serial, -drive, ... (onboard devices) >>>> >>>> * Set the property with -device, or, if you feel masochistic, with >>>> -set device (pluggable devices) >>>> >>>> * Set the property with -global (both) >>>> >>>> The trouble is -global is terrible. >>>> >>>> It gets applied in object_new(), which can't fail. We treat failure >>>> to apply -global as fatal error, except when hot-plugging, where we >>>> treat it as warning *boggle*. I'm not addressing that today. >>>> >>>> Some code falls apart when you use both -global and the other way. >>>> >>>> To make life more interesting, we gave -drive two roles: with >>>> interface type other than none, it's for configuring onboard devices, >>>> and with interface type none, it's for defining backends for use with >>>> -device and such. Since we neglect to require interface type none for >>>> the latter, you can use one -drive in both roles. This confuses the >>>> code about as much as you, dear reader, probably are by now. >>>> >>>> Because this still isn't interesting enough, there's yet another way >>>> to configure backends, just for floppies: set the floppy controller's >>>> property. Goes back to the time when floppy wasn't a separate device, >>>> and involves some Bad Magic. Now -global can interact with itself! >>>> >>>> Digging through all this took me an embarrassing amount of time. >>>> Hair, too. >>>> >>>> My patches reject some the silliest uses outright, and deprecate some >>>> not so silly ones that have replacements. >>>> >>>> Apply on top of my "[PATCH v2 00/58] qdev: Rework how we plug into the >>>> parent bus". >>>> >>> >>> Oof. Thank you for your work in fixing our darkest corners. I sincerely >>> appreciate it. >>> >>> The qdev tree ordering problems don't cause any issues for migration, do >>> they? >> >> This series should only change device configuration, not device state or >> its encoding in the migration stream. >> >> I'm not sure what you mean by "qdev tree ordering problems". Ist it >> commit e8c9e65816 'qom: Make "info qom-tree" show children sorted'? >> >>> (I see you already sent a PR, so whatever!) >> >> A question that might avoid a later migration debugging session is >> *never* "whatever"! >> > > I thought I had read that one of these patches changes the order in > which devices get instantiated, which I thought might change their QOM > paths. Which I thought *might* have some ramifications for migration, > but wasn't sure. Device instantiation order changes should not break migration. The order in which devices appear in the migration stream should not matter. > If it's just showing the same path outputs *sorted*, then there's no > problem. > > Likely misread. > > --js
