> > >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
