On 12/12/23 13:07, Peter Krempa wrote: > On Tue, Dec 12, 2023 at 12:50:52 +0100, Michal Privoznik wrote: >> Virtiofsd has two implementations: C and Rust. The former is now >> deprecated (QEMU commit v7.0.0-rc0~52^2~1) and in fact removed >> from QEMU (QEMU commit v8.0.0-rc0~55). While Rust version was >> originally a drop in replacement it is not the case anymore. Some >> arguments are silently ignored (like file locking) and there's no >> way to make them work for both implementations. >> >> Remove support for the C implementation. > > Note that the virtiofs support in qemu seems to start dating from > qemu-5.0 thus was already availabile at least in RHEL/CentOS 8 > > Now the rust version: > > https://repology.org/project/virtiofsd/versions > > is not available there. > > Since according to our platform support policy we're still about to > support rhel-8 for another ~7 months I'm not sure we should be doing > this. At least not with any form of proper justification, that this > commit message is not providing. > Fair enough. I've noticed some warnings emitted by virtiofsd when I was debugging something else and I thought: let's fix them. And while Rust version was supposed to be a drop in replacement it's not the case anymore (though - I wonder if that ever was the case) as it has moved on. Now, what we usually do in this case is: capabilities. We could run the binary and try to guess if it is C or Rust version. But writing all of that code just so that it can be deleted in ~7 months, just no. So let's keep the code as is and these can be applied after RHEL-8 is dropped. Though, one could argue that the set of users that runs libvirt from git but qemu from repo on RHEL/CentOS 8 is relatively small, the rule we have is a bit different. Michal _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
