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