[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241106040705-mutt-send-email-mst@kernel.org>
Date: Wed, 6 Nov 2024 04:07:44 -0500
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>,
Stefano Garzarella <sgarzare@...hat.com>, stefanha@...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
On Wed, Oct 02, 2024 at 07:16:02AM -0700, Jakub Kicinski wrote:
> On Mon, 30 Sep 2024 19:03:52 +0200 Aleksandr Mikhalitsyn wrote:
> > > At this point my question is, should we solve the problem higher and
> > > show all the modules in /sys/modules, either way?
> >
> > Probably, yes. We can ask Luis Chamberlain's opinion on this one.
> >
> > +cc Luis Chamberlain <mcgrof@...nel.org>
> >
> > >
> > > Your use case makes sense to me, so that we could try something like
> > > that, but obviously it requires more work I think.
> >
> > I personally am pretty happy to do more work on the generic side if
> > it's really valuable
> > for other use cases and folks support the idea.
>
> IMHO a generic solution would be much better. I can't help but feel
> like exposing an arbitrary version to get the module to show up in
> sysfs is a hack.
>
> IIUC the list of built in modules is available in
> /lib/modules/*/modules.builtin, the user space can't read that?
So what are we doing about this? Aleksandr?
--
MST
Powered by blists - more mailing lists