[libvirt] [PATCH 4/8] conf: Allow NULL for virDomainDeviceInfoCallback

Andrea Bolognani abologna at redhat.com
Wed May 22 13:36:59 UTC 2019


On Tue, 2019-05-21 at 16:28 +0200, Ján Tomko wrote:
> On Mon, May 20, 2019 at 03:24:06PM +0200, Andrea Bolognani wrote:
> > On Mon, 2019-05-20 at 14:59 +0200, Ján Tomko wrote:
> > > Of course, there is a huge overlap between iterating over all devices
> > > and just those with an info, but since the callers do request *Info*
> > > I don't think they should expect it to be NULL.
> > 
> > I realize that. I even toyed with the idea of renaming
> > virDomainDeviceInfoIterate() to virDomainDeviceIterate() to get rid
> > of the inconsistency, but I didn't feel like it would be worth the
> > churn and though that documenting the expectations would be enough.
> 
> I think there would be less churn that way, see my proposal:
> Message-Id: <cover.1558448715.git.jtomko at redhat.com>
> https://www.redhat.com/archives/libvir-list/2019-May/msg00607.html

Well of course you're avoiding most of the churn I was mentioning:
you're adding a new function instead of renaming the existing one!
That's cheating ;)

I don't much like the idea of adding a separate function that does
almost the same thing but not quite, because that will ultimately
result in the same situation we have now: someone will add a new
callback and (reasonably) expect it to be called for all devices,
but that won't happen because the original code uses the DeviceInfo
variant instead of the Device one. That's unnecessary friction.

Not to mention that your new function also happens to iterate over
all consoles, which the existing variant doesn't. That's an extra
little inconsistency that we really don't need to introduce.

So I still prefer my approach. As said earlier, I'm also not entirely
convinced keeping the existing function name is a good idea, so I'll
happily rename it at the same time as I'm updating and documenting
its contract. Especially once that's done, I don't see any problem
with passing the callback a pointer that might be NULL and expecting
the user to check before using it, as that's par for the course when
using the C language.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list