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