On Wed, Mar 26, 2025 at 10:38:11AM +0100, Markus Armbruster wrote: > I'm not speaking for the QEMU project. I hope to be helpful anyway. I > am the QAPI maintainer, so my thoughts carry a bit more weight there. > > I understand your block driver depends on your libvitastor_client > library. > > Dependencies that aren't available on at least one supported build > platform (and thus covered by CI) are problematic. For Linux, > "available" generally means "provided by the distribution". I doubt > there's a way around getting your library packaged by distributions. > > The QAPI schema is (for better or worse) fixed at compile time by > design. Changing that would be a major undertaking. Whether the > benefits could justify the costs and risks seems rather doubtful to me. > > In my experience, the project invites contributions, not out-of-tree > extensions. The latter require external interfaces, which can only be > harder to maintain than internal ones. There's also the risk of abuse > to circumvent the GPL (I have absolutely no reason to assume you'd try > that!).
I want to share experience with QEMU block drivers over the years. Special-purpose QEMU block drivers are being used less in favor of host kernel drivers. Kernel drivers make the storage available to all workloads (e.g. containers) on the system, not just QEMU VMs. In particular, it reduces the amount of QEMU-specific support needed to integrate into orchestration software (e.g. Kubernetes). Just a single storage plugin for, say, Kubernetes, enables both container and VM workloads if you provide a host kernel driver for your storage. There can be performance advantages of implementing a QEMU block driver compared to a host kernel driver, but I think in the long term it's worth prioritizing a host kernel driver because it will reduce maintenance for you and make your storage usable with more types of workloads. But the decision is up to you. A QEMU block driver might be preferrable. Some more details about what Markus mentioned: The first step is to ensure that dependencies are under licenses that are compatible with the GPLv2. If you want the block driver to be widely available to users, the next step is to get dependencies packaged for for popular Linux distros. The distro's QEMU packages need to link against the dependencies, so they need to be in the distribution's package repositories, not in third-party repositories. Alternatively, if you will continue to distribute your own QEMU and do not want to go through the effort of getting the dependencies into distros, then you could contribute continuous integration (CI) jobs that build with the third-party dependencies. However, the disadvantage is that most users will be unable to use the block driver and the userbase will be greatly limited. Both of these approaches put the block driver (and associated QAPI schema changes) in qemu.git/master and you would be the maintainer of the block driver. Stefan
signature.asc
Description: PGP signature
