From: Heiner Kallweit <hkallweit1@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alex Williamson <alex.williamson@redhat.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH 2/3] vfio/mdev: inline needed class_compat functionality
Date: Wed, 4 Dec 2024 18:01:36 +0100 [thread overview]
Message-ID: <fb0fc57d-955f-404e-a222-e3864cce2b14@gmail.com> (raw)
In-Reply-To: <2024120430-boneless-wafer-bf0c@gregkh>
On 04.12.2024 10:32, Greg Kroah-Hartman wrote:
> On Tue, Dec 03, 2024 at 09:11:47PM +0100, Heiner Kallweit wrote:
>> vfio/mdev is the last user of class_compat, and it doesn't use it for
>> the intended purpose. See kdoc of class_compat_register():
>> Compatibility class are meant as a temporary user-space compatibility
>> workaround when converting a family of class devices to a bus devices.
>
> True, so waht is mdev doing here?
>
>> In addition it uses only a part of the class_compat functionality.
>> So inline the needed functionality, and afterwards all class_compat
>> code can be removed.
>>
>> No functional change intended. Compile-tested only.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/vfio/mdev/mdev_core.c | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
>> index ed4737de4..a22c49804 100644
>> --- a/drivers/vfio/mdev/mdev_core.c
>> +++ b/drivers/vfio/mdev/mdev_core.c
>> @@ -18,7 +18,7 @@
>> #define DRIVER_AUTHOR "NVIDIA Corporation"
>> #define DRIVER_DESC "Mediated device Core Driver"
>>
>> -static struct class_compat *mdev_bus_compat_class;
>> +static struct kobject *mdev_bus_kobj;
>
>
>
>>
>> static LIST_HEAD(mdev_list);
>> static DEFINE_MUTEX(mdev_list_lock);
>> @@ -76,7 +76,7 @@ int mdev_register_parent(struct mdev_parent *parent, struct device *dev,
>> if (ret)
>> return ret;
>>
>> - ret = class_compat_create_link(mdev_bus_compat_class, dev, NULL);
>> + ret = sysfs_create_link(mdev_bus_kobj, &dev->kobj, dev_name(dev));
>
> This feels really wrong, why create a link to a random kobject? Who is
> using this kobject link?
>
>> if (ret)
>> dev_warn(dev, "Failed to create compatibility class link\n");
>>
>> @@ -98,7 +98,7 @@ void mdev_unregister_parent(struct mdev_parent *parent)
>> dev_info(parent->dev, "MDEV: Unregistering\n");
>>
>> down_write(&parent->unreg_sem);
>> - class_compat_remove_link(mdev_bus_compat_class, parent->dev, NULL);
>> + sysfs_remove_link(mdev_bus_kobj, dev_name(parent->dev));
>> device_for_each_child(parent->dev, NULL, mdev_device_remove_cb);
>> parent_remove_sysfs_files(parent);
>> up_write(&parent->unreg_sem);
>> @@ -251,8 +251,8 @@ static int __init mdev_init(void)
>> if (ret)
>> return ret;
>>
>> - mdev_bus_compat_class = class_compat_register("mdev_bus");
>> - if (!mdev_bus_compat_class) {
>> + mdev_bus_kobj = class_pseudo_register("mdev_bus");
>
> But this isn't a class, so let's not fake it please. Let's fix this
> properly, odds are all of this code can just be removed entirely, right?
>
After I removed class_compat from i2c core, I asked Alex basically the
same thing: whether class_compat support can be removed from vfio/mdev too.
His reply:
I'm afraid we have active userspace tools dependent on
/sys/class/mdev_bus currently, libvirt for one. We link mdev parent
devices here and I believe it's the only way for userspace to find
those parent devices registered for creating mdev devices. If there's a
desire to remove class_compat, we might need to add some mdev
infrastructure to register the class ourselves to maintain the parent
links.
It's my understanding that /sys/class/mdev_bus has nothing in common
with an actual class, it's just a container for devices which at least
partially belong to other classes. And there's user space tools depending
on this structure.
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2024-12-04 17:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 20:08 [PATCH 0/3] driver core: class: remove class_compat code Heiner Kallweit
2024-12-03 20:10 ` [PATCH 1/3] driver core: class: add class_pseudo_register Heiner Kallweit
2024-12-04 9:33 ` Greg Kroah-Hartman
2024-12-04 17:04 ` Heiner Kallweit
2024-12-04 18:17 ` Greg Kroah-Hartman
2024-12-04 19:35 ` Heiner Kallweit
2024-12-03 20:11 ` [PATCH 2/3] vfio/mdev: inline needed class_compat functionality Heiner Kallweit
2024-12-04 9:32 ` Greg Kroah-Hartman
2024-12-04 17:01 ` Heiner Kallweit [this message]
2024-12-04 18:16 ` Greg Kroah-Hartman
2024-12-04 19:30 ` Alex Williamson
2024-12-06 7:35 ` Heiner Kallweit
2024-12-06 7:42 ` Greg Kroah-Hartman
2024-12-06 16:37 ` Alex Williamson
2024-12-07 8:38 ` Greg Kroah-Hartman
2024-12-07 10:06 ` Heiner Kallweit
2024-12-07 10:23 ` Greg Kroah-Hartman
2024-12-12 4:42 ` Christoph Hellwig
2024-12-12 18:12 ` Alex Williamson
2024-12-12 18:21 ` Greg Kroah-Hartman
2024-12-12 18:39 ` Alex Williamson
2024-12-13 14:53 ` Christoph Hellwig
2024-12-06 17:05 ` Heiner Kallweit
2024-12-04 19:35 ` Heiner Kallweit
2025-01-10 14:35 ` Greg Kroah-Hartman
2025-01-13 22:09 ` Alex Williamson
2024-12-03 20:12 ` [PATCH 3/3] driver core: class: remove class_compat code Heiner Kallweit
2024-12-12 4:27 ` [PATCH 0/3] " Christoph Hellwig
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=fb0fc57d-955f-404e-a222-e3864cce2b14@gmail.com \
--to=hkallweit1@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=rafael@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox