On Thu, Nov 14, 2024 at 03:47:20PM -0500, Peter Xu wrote: > On Mon, Nov 11, 2024 at 03:55:53PM +0000, Daniel P. Berrangé wrote: > > qdev_new() has a failure scenario where it will assert() if given > > an abstract type. Callers which are creating qdevs based on user > > input, or unknown/untrusted type names, must manually check the > > result of qdev_class_is_abstract() before calling qdev_new() > > to propagate an Error, instead of asserting. > > > > Introduce a qdev_new_dynamic() method which is a counterpart to > > qdev_new() that directly returns an Error, instead of asserting. > > This new method is to be used where the typename is specified > > dynamically by code separate from the immediate caller. > > > > Do likewise with qdev_try_new_dynamic() as a counterpart to > > qdev_try_new(). > > Since at it, would it make sense to simply replace qdev_try_new() with > qdev_new_dynamic(), assuming it plays similar role of "it can fail" version > of qdev_new()?
That is tricky as callers of qdev_try_new have to distinguish between expected failures and unexpected failures. That said you made me look at the usage patterns and I concluded these xxx_try_new() methods are a bad design for other reasons, so I have simply eliminated them entirely in v3. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
