> On Thu, Feb 01, 2018 at 12:03:42PM +0000, Wuzongyong (Euler Dept) wrote: > > a mdev > > > > > > On Thu, Feb 01, 2018 at 09:08:59AM +0000, Wuzongyong (Euler Dept) > wrote: > > > > Hi, > > > > > > > > I solve this problem by sending a CHANGE event to userspace after > > > creating the symbol link like sriov driver. > > > > > > > > diff --git a/drivers/vfio/mdev/mdev_core.c > > > > b/drivers/vfio/mdev/mdev_core.c index 1269910..a23f1d7 100644 > > > > --- a/drivers/vfio/mdev/mdev_core.c > > > > +++ b/drivers/vfio/mdev/mdev_core.c > > > > @@ -351,6 +351,8 @@ int mdev_device_create(struct kobject *kobj, > > > > struct > > > device *dev, uuid_le uuid) > > > > goto create_failed; > > > > } > > > > > > > > + kobject_uevent(&(mdev->dev.kobj), KOBJ_CHANGE); > > > > + > > > > mdev->type_kobj = kobj; > > > > dev_dbg(&mdev->dev, "MDEV: created\n"); > > > > > > > > Is this patch ok? > > > > > > I'm not really familiar with kernel, but from a layman's point of > > > view, the ADD and CHANGE event should be clearly distinguished, but > > > here you expect the CHANGE event to be the result of creating the > > > sysfs entry, whereas in general you'd expect this from the ADD > > > event, since it's really the object has just been created for the > first time, right? > > > > > > Erik > > > > > > > The ADD event has been sended before sending CHANGE event. And before > > sending ADD event, the mdev sysfs file node and some general attribute > > such as power/uevent has been created, but the mdev_type file(link > > libvirt want to resolve) has not been created yet. So I think maybe we > > should send a CHANGE event to tell libvirt this link has been created so > libvirt can resolve it correctly. > > Well, as much beneficial as getting an event from udev can be, it wouldn't > change anything within libvirt really, since when we get the ADD event, we > try to wait for the link to appear and only then continue. With the CHANGE > event we'll update the device again. I'm only saying it because we'll be > supporting running upstream on kernels prior to this potential change/fix, > so it will take "a few" years until libvirt is going to solely rely on > udev events here. > > The commit ID you asked in the other mail is 1af45804. > > Erik Yes, you are right. I forgot to take the case that kernels prior to this potential change into account. Thanks, Zongyong Wu -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
