On Tue, May 17, 2022 at 12:21:03PM +0000, Parav Pandit wrote: > Hi Greg, Yongji, > > > From: Yongji Xie <xieyongji@xxxxxxxxxxxxx> > > Sent: Tuesday, May 17, 2022 3:25 AM > > > > On Tue, May 17, 2022 at 4:06 AM Parav Pandit <parav@xxxxxxxxxx> wrote: > > > > > > > > > > > > > From: Xie Yongji <xieyongji@xxxxxxxxxxxxx> > > > > Sent: Monday, May 16, 2022 2:04 AM > > > > > > > > Introduce a device object for vdpa management device to control its > > > > lifecycle. > > > Why is this needed? > > > What is the limitation of current approach that requires new device for > > mgmtdev? > > > The primary motivation is missing in the commit log here. > > > > > > > OK, I will add one. This patch actually comes from the discussion: > > > > > > https://www.spinics.net/lists/linux-virtualization/msg56371.html > > > > The "vdpa_mgmt_dev" makes things a little confusing. Embedding the > > device struct in it to control its lifecycle simplifies the logic and makes the > > driver model clear. > > > No. it doesn't. > > vdpa_mgmt_dev is really the handle for all the netlink socket messages targeted. > It is not really a struct device. Why can it not be one? It has lifetime rules that must be followed, so might as well use the built-in code to handle this, right? What is wrong with it being a struct device? > We can rename it to vdpa_mgmt_handle, if the _dev suffix is confusing. Where is the "management" device if this is not that? What does "handle" mean here? > And regarding vduse_dev_release() and existing empty release function, they can be dynamically allocated. > This is because they are really the struct device. I do not understand this statement, sorry. thanks, greg k-h _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
