lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a4e8d2ac-a303-4c5b-9a1d-3ba6c09d92dc@lunn.ch>
Date: Mon, 30 Sep 2024 21:47:58 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Cc: Stefano Garzarella <sgarzare@...hat.com>, kuba@...nel.org,
	stefanha@...hat.com, "Michael S. Tsirkin" <mst@...hat.com>,
	Jason Wang <jasowang@...hat.com>,
	Eugenio PĂ©rez <eperezma@...hat.com>,
	kvm@...r.kernel.org, virtualization@...ts.linux.dev,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	mcgrof@...nel.org
Subject: Re: [PATCH v2] vhost/vsock: specify module version

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ