All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
	Tony Krowiak <akrowiak@linux.ibm.com>,
	Harald Freudenberger <freude@linux.ibm.com>,
	linux-s390@vger.kernel.org, Halil Pasic <pasic@linux.ibm.com>,
	Jason Herne <jjherne@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [RFC PATCH] s390: vfio-ap: Register the vfio_ap module for the "ap" parent bus
Date: Wed, 15 Dec 2021 13:51:02 +0100	[thread overview]
Message-ID: <87tufaqbex.fsf@redhat.com> (raw)
In-Reply-To: <6aaf6c60-a258-29e3-fcec-82c77d3945a4@redhat.com>

On Wed, Dec 15 2021, Thomas Huth <thuth@redhat.com> wrote:

> On 14/12/2021 22.55, Tony Krowiak wrote:
>> 
>> 
>> On 12/13/21 11:11, Cornelia Huck wrote:
>>> One possibility is simply blocking autoload of the module in userspace by
>>> default, and only allow it to be loaded automatically when e.g. qemu-kvm
>>> is installed on the system. This is obviously something that needs to be
>>> decided by the distros.
>>>
>>> (kvm might actually be autoloaded already, so autoloading vfio-ap would
>>> not really make it worse.)
>> 
>> Of the vfio_ccw module is automatically loaded, then the kvm
>> module will also get loaded. I startup up a RHEL8.3 system and
>> sure enough, the vfio_ccw module is loaded along with the
>> kvm, vfio and mdev modules. If this is true for all distros, then
>> it wouldn't make much difference if the vfio_ap module is
>> autoloaded too.
>
> I think I don't mind too much if we auto-load vfio-ap or not - but I think 
> we should make it consistent with vfio-ccw. So either auto-load both modules 
> (if the corresponding devices are available), or remove the 
> MODULE_DEVICE_TABLE() entries from both modules?

I think we really need to take a step back and think about the purpose
of adding a MODULE_DEVICE_TABLE()... basically, it declares which types
of devices on a certain bus a driver supports, in a way that can be
consumed by userspace (after file2alias.c worked on it).

Userspace typically uses this to match devices it is notified about to
drivers that could possibly drive those devices. In general, the
assumption is that you will want to have the drivers for your devices
loaded. In some cases (drivers only used in special cases, like here),
it might be a better idea to autoload the drivers only under certain
circumstances (e.g. if you know you're going to run KVM guests).

My main point, however, is that we're talking about policy here: whether
a potentially useful driver should be loaded or not is a decision that
should be made by userspace. Not providing a MODULE_DEVICE_TABLE does
not look like the right solution, as it deprives userspace of the
information to autoload the driver, if it actually wants to do so.


  reply	other threads:[~2021-12-15 12:51 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01 14:11 [RFC PATCH] s390: vfio-ap: Register the vfio_ap module for the "ap" parent bus Thomas Huth
2021-12-01 17:10 ` Harald Freudenberger
2021-12-02  7:13   ` Thomas Huth
2021-12-02  8:33     ` Harald Freudenberger
2021-12-03 19:26       ` Tony Krowiak
2021-12-08 13:46       ` Thomas Huth
2021-12-08 14:25         ` Cornelia Huck
2022-01-27 14:41           ` Tony Krowiak
2022-01-27 14:23       ` Tony Krowiak
2022-01-31 11:03         ` Harald Freudenberger
2021-12-13 15:44 ` Harald Freudenberger
2021-12-13 16:11   ` Cornelia Huck
2021-12-14 21:55     ` Tony Krowiak
2021-12-15 12:05       ` Thomas Huth
2021-12-15 12:51         ` Cornelia Huck [this message]
2021-12-15 14:38           ` Thomas Huth
2021-12-15 23:02           ` Halil Pasic
2021-12-16 10:39             ` Cornelia Huck
2021-12-16 11:25               ` Halil Pasic
2022-01-27 15:04             ` Tony Krowiak
2022-01-28  1:35               ` Halil Pasic
2022-01-27 14:48           ` Tony Krowiak
2022-01-27 14:46     ` Tony Krowiak
2021-12-14 21:28   ` Tony Krowiak
2022-01-27 10:33     ` Thomas Huth
2022-01-27 15:10       ` Tony Krowiak
2021-12-16  9:50   ` Harald Freudenberger
2021-12-16 10:44     ` Cornelia Huck
2022-01-27 14:45   ` Tony Krowiak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tufaqbex.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.ibm.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.