Re: [PATCH v2] vhost/vsock: specify module version

[Andrew Lunn <andrew@lunn.ch>]

> > >Hi Stefano,
> > >
> > >>
> > >> I was looking at other commits to see how versioning is handled in order
> > >> to make sense (e.g. using the same version of the kernel), and I saw
> > >> many commits that are removing MODULE_VERSION because they say it
> > >> doesn't make sense in in-tree modules.
> > >
> > >Yeah, I agree absolutely. I guess that's why all vhost modules have
> > >had version 0.0.1 for years now
> > >and there is no reason to increment version numbers at all.
> >
> > Yeah, I see.
> >
> > >
> > >My proposal is not about version itself, having MODULE_VERSION
> > >specified is a hack which
> > >makes a built-in module appear in /sys/modules/ directory.
> >
> > Hmm, should we base a kind of UAPI on a hack?
> 
> Good question ;-)
> 
> >
> > I don't want to block this change, but I just wonder why many modules
> > are removing MODULE_VERSION and we are adding it instead.
> 
> Yep, that's a good point. I didn't know that other modules started to
> remove MODULE_VERSION.

As you said, all over vhost modules say version 0.0.1 for years. But
the kernel around these modules has had many changes. So 0.0.1 tells
you nothing useful. When a user reports a problem using vhost_vsock
version 0.0.1 your first question is going to be, what kernel version
from which distribution?

If the information is useless, let just remove it.

I would not base a kAPI around this. Isn't there a system call you can
perform and get an EOPNOTSUPP, ENODEV, EMORECOFFEE?

Also, at least in networking and probably in other subsystems,
performing an operation is often needed to trigger the module to
load. So it not being listed in /sys/modules does not mean the module
is missing, it could be its just not been needed until now.

Take a step back, what is your real use case here? Describe it and
maybe we can think of a better kAPI.

	Andrew