All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Cornelia Huck <cohuck@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/8] vfio: Rename __vfio_group_unset_container()
Date: Tue, 6 Sep 2022 20:06:30 -0300	[thread overview]
Message-ID: <YxfSdsfux0NEYmNW@nvidia.com> (raw)
In-Reply-To: <20220906133811.16031613.alex.williamson@redhat.com>

On Tue, Sep 06, 2022 at 01:38:11PM -0600, Alex Williamson wrote:

> I might refine these to:
> 
> struct vfio_container *vfio_container_from_file(struct file *filep);
> 
> int vfio_group_use_container(struct vfio_group *group);
> void vfio_group_unuse_container(struct vfio_group *group);
> 
> int vfio_container_attach_group(struct vfio_container *container,
> 				struct vfio_group *group);
> void vfio_group_detach_container(struct vfio_group *group);

IMHO it is weird to sacrifice the clear pair'd naming, keep the group
first?

> void vfio_device_container_register(struct vfio_device *device);
> void vfio_device_container_unregister(struct vfio_device *device);
> 
> long vfio_container_ioctl_check_extension(struct vfio_container *container,
>  					  unsigned long arg);

I'm fine with all of these, if you like it I'll change it - it is a
lot of work to change the names and rebase everything so please lets
all agree first.

> int vfio_device_pin_container_pages(struct vfio_device *device, dma_addr_t iova,
> 				    int npage, int prot, struct page **pages);
> void vfio_device_unpin_container_pages(struct vfio_device *device, dma_addr_t
> 				       iova, int npage);
> 
> int vfio_device_dma_rw_container(struct vfio_device *device, dma_addr_t iova,
> 				 void *data, size_t len, bool write);

These are exported symbols and I don't want to mess with them. The
fact they are in container.c is temporary artifact, as they do touch
the struct vfio_container. The iommufd series puts a wrapper in main.c
and the above can have signatures that only take in a container * -
which is what you suggest below. So lets leave them alone here.

> Overall, I'm still not really on board with sacrificing a "the name
> tells you how to use it" API in order to break down devices, groups,
> and containers into their own subsystems.  We should not only consider
> the logical location of the function, but the usability and
> intuitiveness of the API.

Sure, I'm not set on any particular naming scheme.

> Are we necessarily finding the right splits here?  The {un}use,
> {un}pin, and dma_rw in particular seem like they could be decomposed
> further.  

I can't think how to do anything better for {un}use. They are in
container.c because the entire container_users mechanism is gone when
the container code is gone, even though the mechanism is part of the
struct vfio_group. unuse doesn't even touch the vfio_container..

Lets just leave them with their group names and they slightly oddly
stay in container.c

> vfio_container_{un}use() with a vfio_container object.  Or a
> vfio_device intermediary that can call vfio_container_ functions for
> {un}pin/rw, also with a container object.  Thanks,

Some of the split is an artifact of how the code is right now. I don't
think you'd end up with exactly this interface if you designed it from
scratch, but we have what we have, and I don't have a lot of
enthusiasm to restructure significantly for the sake of naming..

Thanks,
Jason

  reply	other threads:[~2022-09-06 23:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31  1:01 [PATCH 0/8] vfio: Split the container code into a clean layer and dedicated file Jason Gunthorpe
2022-08-31  1:01 ` [PATCH 1/8] vfio: Add header guards and includes to drivers/vfio/vfio.h Jason Gunthorpe
2022-08-31  8:42   ` Tian, Kevin
2022-08-31 15:36     ` Jason Gunthorpe
2022-08-31 18:02       ` Alex Williamson
2022-08-31 18:24         ` Jason Gunthorpe
2022-09-01  2:17           ` Tian, Kevin
2022-08-31  1:01 ` [PATCH 2/8] vfio: Rename __vfio_group_unset_container() Jason Gunthorpe
2022-08-31  8:46   ` Tian, Kevin
2022-09-02  0:28     ` Jason Gunthorpe
2022-09-02  3:51       ` Tian, Kevin
2022-09-02 14:39         ` Alex Williamson
2022-09-02 16:24           ` Jason Gunthorpe
2022-09-06  3:35             ` Tian, Kevin
2022-09-06 19:38               ` Alex Williamson
2022-09-06 23:06                 ` Jason Gunthorpe [this message]
2022-08-31  1:01 ` [PATCH 3/8] vfio: Split the container logic into vfio_container_attach_group() Jason Gunthorpe
2022-08-31  8:47   ` Tian, Kevin
2022-09-02  0:42     ` Jason Gunthorpe
2022-08-31  1:01 ` [PATCH 4/8] vfio: Remove #ifdefs around CONFIG_VFIO_NOIOMMU Jason Gunthorpe
2022-08-31  8:48   ` Tian, Kevin
2022-08-31 15:28     ` Jason Gunthorpe
2022-09-01  2:18       ` Tian, Kevin
2022-08-31  1:01 ` [PATCH 5/8] vfio: Split out container code from the init/cleanup functions Jason Gunthorpe
2022-08-31  8:49   ` Tian, Kevin
2022-08-31  1:02 ` [PATCH 6/8] vfio: Rename vfio_ioctl_check_extension() Jason Gunthorpe
2022-08-31  8:50   ` Tian, Kevin
2022-08-31  1:02 ` [PATCH 7/8] vfio: Split the register_device ops call into functions Jason Gunthorpe
2022-09-02  3:52   ` Tian, Kevin
2022-08-31  1:02 ` [PATCH 8/8] vfio: Move container code into drivers/vfio/container.c Jason Gunthorpe

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=YxfSdsfux0NEYmNW@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.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 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.