On a Thursday in 2023, Michal Prívozník wrote:
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.
Running the binary and guessing stuff is the approach we took when we
used to parse QEMU's --help output. I'm glad that code is gone and
I hope we don't have to do any guessing in the future.
For virtiofsd users, most will have the vhost-user json file:
$ cat /usr/share/qemu/vhost-user/50-qemu-virtiofsd.json
{
"description": "QEMU virtiofsd vhost-user-fs",
"type": "fs",
"binary": "/usr/libexec/virtiofsd"
}
which can in theory contain some hints/capabilities that would let us
tell them apart.
I reported the bug against virtiofsd:
https://issues.redhat.com/browse/RHEL-7415
However the discussion died out and I did not volunteer any patches,
since I don't like writing code that should be deleted soon.
The approach however won't work for some old RHEL/CentOS releases,
where the .json file was installed in some weird location and in cases
where the user supplies their own path to the virtiofsd binary (e.g.
to some build from git) - the former will likely use the old options,
while the git build will probably have the new ones.
(Also note that the ~7 months deadline is for RHEL/CentOS, Peter did not
check whether other distros still ship the old virtiofsd.)
Jano
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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
