Peter Maydell <peter.maydell@xxxxxxxxxx> writes: > On Thu, 31 Jan 2019 at 08:52, Markus Armbruster <armbru@xxxxxxxxxx> wrote: >> Lesson for the future: when we correct something, but don't dare to >> touch (some) existing uses (being not "reasonably sure it doesn't >> actually break guests that used to work"), we should at least have >> enough sense to make "incorrect" opt-in rather than opt-out! People >> adding new uses will be blissfully unaware of the need to opt-out, and >> the problem will multiply, just like it did here. > > The theory was that pflash_cfi01_register() is the legacy > back-compat API, and new board models use new style > "create the device and set its properties longhand", I think. > (This is part of a wider issue that the preferred QOM APIs > tend to be more longwinded than the old obsolete helper > functions.) It's definitely unfortunate that we didn't > at least comment that that function shouldn't be used in > new boards. > > The problem hasn't multiplied very much -- almost all the > users of pflash_cfi01_register() predate the change. > > I'm not sure what an API that defaulted to 'correct' would > look like here, though. What about this: 1. Make the device model default to some "correct" configuration, even if that setting is kind of arbitrary. That way, any code using new style gets an "incorrect" configuration only if it actively selects one. 2. Won't help with pflash_cfi01_register(), which actively selects whatever configuration it gets passed. Not a serious problem as long as it doesn't get used by new code, so rename it to pflash_cfi01_create_legacy() and give it a fat comment. 3. Convert one or more of its users to the new style, so we have good examples, not just bad ones. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
