Runtime: Use "virtiofs" instead of "virtio_fs" for the virtio-fs module

[fidencio]

Description of problem

In the early stages of virtio-fs development, its module was called "virtio_fs". However, it's changed to "virtiofs" and that's the name used upstream.

Whenever we're trying to use a new enogh kernel, we'd look for virtio_fs instead of "virtiofs" causing a failure to load the module.

Expected result

Work with the new enough kernels.

Actual result

Doesn't work with new enough kernels.

NOTE: It's important to note that I'm not exactly familiar with the kata project with regards to when the kernel used by the project would / should be updated in order to reflect the changes I'm asking for in this bug report.

[grahamwhaley]

/cc @dagrh

[dagrh]

I think this is the right way to go. My only question for @grahamwhaley is whether we need to step the kernel version kata is using for ci firs/at the same time.

[grahamwhaley]

@dagrh good point about the CIs. This is 'host kernel', yes? @chavafg - I'm going to guess we don't have control over all the CI host kernel versions...
How about we search for the new/real name first (virtiofs), and if that fails, then we search for the old name as a backup (virtio_fs) - gives us both a safety net for the CI systems, and also should allow any current or future users with older kernels to continue working?
/cc @devimc

[dagrh]

No, this is guest kernel.

[c3d]

Even if it's the guest kernel, I think you should, at least for a transition period, be ready for both.

[c3d]

@grahamwhaley The last commit that refers to virtio_fs seems to be this one:
https://github.com/torvalds/linux/commit/112e72373d1f60f1e4558d0a7f0de5da39a1224d

Dated October 11, 2019. I think it's safe to proceed as if there is only virtiofs to consider now, given that there was a really short window where virtio_fs was useful, and it always required some sort of bleeding edge kernel and qemu to make it work.

[fidencio]

So, I'd personally prefer to:

• Have a 1.11.0 release at some point soon;
• From 1.12.0 onwards, require 5.4 kernel.

If we really have to deal with compatibility with both virtiofs and virtio_fs, we may end up having to adapt the code in several different places with no much gain.

Does the suggestion make sense?

[amshinde]

@fidencio We had been on the 4.19 longterm kernel for a while, and recently updated to LTS kernel version of 5.14.15. Related PR :https://github.com/kata-containers/runtime/pull/2422

However, we had started off with using different kernel in our CI for virtiofs when experimental support for virtiofs was first added as seen here:
https://github.com/kata-containers/runtime/blob/master/versions.yaml#L111

I believe that particular kernel is based on version 5.3. We havent yet switched to using the 5.14.15 kernel yet for virtiofs as the 5.4 version is missing certain DAX patches:
https://github.com/kata-containers/runtime/pull/2422#issuecomment-585103897

We should probably update the virtiofs kernel under https://gitlab.com/virtio-fs/linux.git to be based on 5.4 kernel with any extra patches required for virtiofs dax support.

[jongwu]

Hi @amshinde @grahamwhaley , as kata will choose kernel 5.4 as LTS, what about applying the missing patch for virtiofs to 5.4 kernel and forget virtiofs-0.3. so we can maintain a single kernel to avoid those out of order issue.