From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
"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: Thu, 12 Dec 2024 19:21:34 +0100 [thread overview]
Message-ID: <2024121256-goon-ashamed-2339@gregkh> (raw)
In-Reply-To: <20241212111200.79b565e1.alex.williamson@redhat.com>
On Thu, Dec 12, 2024 at 11:12:00AM -0700, Alex Williamson wrote:
> On Wed, 11 Dec 2024 20:42:06 -0800
> Christoph Hellwig <hch@infradead.org> wrote:
> > On Sat, Dec 07, 2024 at 11:06:15AM +0100, Heiner Kallweit wrote:
> > > Issue with this approach is that these "mdev parent" devices are partially
> > > class devices belonging to other classes. See for example mtty_dev_init(),
> > > there the device passed to us belongs to class mtty.
> >
> > The samples don't matter and can be fixed any time. Or even better
> > deleted.
>
> There is value to these. In particular mtty exposes a dummy PCI serial
> device with two different flavors (single/dual port) that's useful for
> not only testing the mdev lifecycle behavior, but also implements the
> vfio migration API. Otherwise testing any of this requires specific
> hardware. I'd agree that breaking userspace API for a sample device is
> less of a blocking issue, but then we have these...
>
> > The real question is if the i915, ccw and ap devices are
> > class devices. From a quick unscientific grep they appear not to,
> > but we'd need to double check that.
>
> And I'd expect that these are all linking bus devices under the
> mdev_bus class. I understand the issue now, that from the start we
> should have been creating class devices, but it seems that resolving
> that is going to introduce a level of indirection between the new class
> device and the bus device which is likely going to have dependencies in
> the existing userspace tools. We'll need to work through the primary
> ones and figure out contingencies for the others to avoid breaking
> userspace. The "just remove it anyway" stance seems to be in conflict
> with the "don't break userspace" policy and I don't think we can
> instantly fix this. Thanks,
But samples are not "real" and are not actually used. If they were,
then shouldn't they be in the real part of the kernel?
So what are we "breaking" here?
confused,
greg k-h
next prev parent reply other threads:[~2024-12-12 18:21 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
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 [this message]
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=2024121256-goon-ashamed-2339@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=alex.williamson@redhat.com \
--cc=hch@infradead.org \
--cc=hkallweit1@gmail.com \
--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