Re: [ANNOUNCE] libblkio v0.1.0 preview release

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

Am 29.04.2021 um 16:05 hat Stefan Hajnoczi geschrieben:
> Hi,
> A preview release of libblkio, a library for high-performance block I/O,
> is now available:
> 
>   https://gitlab.com/libblkio/libblkio/-/tree/v0.1.0
> 
> Applications are increasingly integrating high-performance I/O
> interfaces such as Linux io_uring, userspace device drivers, and
> vhost-user device support. The effort required to add each of these
> low-level interfaces into an application is relatively high. libblkio
> provides a single API for efficiently accessing block devices and
> eliminates the need to write custom code for each one.
> 
> The library is not yet ready to use and currently lacks many features.
> In fact, I hope this news doesn't spread too far yet because libblkio is
> at a very early stage, but feedback from the QEMU community is necessary
> at this time.

I'm a bit worried about the configuration interface. This looks an awful
lot like plain QOM properties, which have proven to result in both very
verbose (not to say messy) and rather error prone implementations.

You have to write setters/getters for every property, even if it usually
ends up doing the same thing, storing the value somewhere. Worse, these
getters and setters have to work in very different circumstances, namely
initialisation where you usually have to store the value away so that it
can be checked for consistency with other properties in .realize() or
.complete(), and property updates during runtime. Often enough, we
forget the latter and create bugs. If we don't create bugs, we usually
start with 'if (realized)' and have two completely different code paths.
Another common bug in QOM objects is forgetting to check if mandatory
properties were actually set.

Did you already consider these problems and decided to go this way
anyway, or is this more of an accidental design? And if the former, what
were the reasons that made it appealing?

Alternatives in QEMU are qdev properties (which are internally QOM
properties, but provide default implementations and are at least
automatically read-only after realize, avoiding that whole class of
bugs) and QAPI.
If this was QEMU code, I would of course go for QAPI, but a library is
something different and adding the code generator would probably be a
bit too much anyway. But the idea in the resulting code would be dealing
with native structs instead of a bunch of function calls. This would
probably be the least error prone way for the implementation, but of
course, it would make binary compatibility a bit harder when adding new
properties.

Thinking a bit further, we'll likely get the same problems as with QOM
in other places, too, e.g. how do you introspect which properties exist
in a given build?

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]