public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Tony Krowiak <akrowiak@linux.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Jason Herne <jjherne@linux.ibm.com>,
	Eric Farman <farman@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Zhenyu Wang <zhenyuw@linux.intel.com>,
	Zhi Wang <zhi.a.wang@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	intel-gvt-dev@lists.freedesktop.org, Neo Jia <cjia@nvidia.com>,
	Dheeraj Nigam <dnigam@nvidia.com>,
	Tarun Gupta <targupta@nvidia.com>
Subject: Re: [PATCH 3/8] vfio/mdev: simplify mdev_type handling
Date: Tue, 7 Jun 2022 07:50:50 +0200	[thread overview]
Message-ID: <20220607055050.GB8680@lst.de> (raw)
In-Reply-To: <86df429e-9f01-7a91-c420-bb1130b4d343@nvidia.com>

On Tue, Jun 07, 2022 at 12:52:49AM +0530, Kirti Wankhede wrote:
>>   	void (*remove)(struct mdev_device *dev);
>> -	struct attribute_group **supported_type_groups;
>>   	struct device_driver driver;
>>   };
>
> mdev_type should be part of mdev_parent, separating it from mdev_parent 
> could result in more errors while using mdev framework.

Why?

> Similarly it should 
> be added as part of mdev_register_device. Below adding types is separated 
> from mdev_register_device which is more error prone.

How so?

> What if driver 
> registering to mdev doesn't add mdev_types? - mdev framework is un-usable 
> in that case.

Yes, so it is if you don't add it to the supported_type_groups field
in the current kernel.  Basic programmer error, and trivially caught.

> We had kept it together with mdev registration so that 
> mdev_types should be mandatory to be defined by driver during registration. 
> How would you mandate mdev_type by such separation?

I would not.  Registering a parent without types is perfectly valid from
the code correctness perspective.  It just isn't very useful.  Just
like say creating a kobject without attributes in the device model.

  reply	other threads:[~2022-06-07  5:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03  6:33 simplify the mdev interface Christoph Hellwig
2022-06-03  6:33 ` [PATCH 1/8] vfio/mdev: make mdev.h standalone includable Christoph Hellwig
2022-06-06 23:21   ` Jason Gunthorpe
2022-06-09  6:43   ` Tian, Kevin
2022-06-03  6:33 ` [PATCH 2/8] vfio/mdev: embedd struct mdev_parent in the parent data structure Christoph Hellwig
2022-06-06 19:22   ` Kirti Wankhede
2022-06-07  5:48     ` Christoph Hellwig
2022-06-09  6:52       ` Tian, Kevin
2022-06-03  6:33 ` [PATCH 3/8] vfio/mdev: simplify mdev_type handling Christoph Hellwig
2022-06-06 19:22   ` Kirti Wankhede
2022-06-07  5:50     ` Christoph Hellwig [this message]
2022-06-08 17:57       ` Kirti Wankhede
2022-06-09  7:16         ` Christoph Hellwig
2022-06-06 23:38   ` Jason Gunthorpe
2022-06-07  5:56     ` Christoph Hellwig
2022-06-03  6:33 ` [PATCH 4/8] vfio/mdev: remove mdev_{create,remove}_sysfs_files Christoph Hellwig
2022-06-06 23:38   ` Jason Gunthorpe
2022-06-09  6:55   ` Tian, Kevin
2022-06-03  6:33 ` [PATCH 5/8] vfio/mdev: remove mdev_from_dev Christoph Hellwig
2022-06-06 23:45   ` Jason Gunthorpe
2022-06-09  6:56   ` Tian, Kevin
2022-06-03  6:33 ` [PATCH 6/8] vfio/mdev: unexport mdev_bus_type Christoph Hellwig
2022-06-06 23:46   ` Jason Gunthorpe
2022-06-09  6:57   ` Tian, Kevin
2022-06-03  6:33 ` [PATCH 7/8] vfio/mdev: remove mdev_parent_dev Christoph Hellwig
2022-06-06 23:46   ` Jason Gunthorpe
2022-06-09  6:58   ` Tian, Kevin
2022-06-03  6:33 ` [PATCH 8/8] vfio/mdev: remove mtype_get_parent_dev Christoph Hellwig
2022-06-06 23:46   ` Jason Gunthorpe
2022-06-09  6:58   ` Tian, Kevin

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=20220607055050.GB8680@lst.de \
    --to=hch@lst.de \
    --cc=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=cjia@nvidia.com \
    --cc=dnigam@nvidia.com \
    --cc=farman@linux.ibm.com \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jjherne@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=targupta@nvidia.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox