On Sat, Aug 10, 2013 at 10:12 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Aug 11, 2013 at 12:53:45AM -0400, Michael Marineau wrote: > > This driver adds an attribute to the existing virtio device so a CHANGE > > event is required in order udev rules to make use of it. The ADD event > > happens before this driver is probed and unlike a more typical driver > > like a block device there isn't a higher level device to watch for. > > > > Signed-off-by: Michael Marineau <michael.marineau@xxxxxxxxxx> > > --- > > net/9p/trans_virtio.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c > > index e1c26b1..990afab 100644 > > --- a/net/9p/trans_virtio.c > > +++ b/net/9p/trans_virtio.c > > @@ -577,6 +577,10 @@ static int p9_virtio_probe(struct virtio_device *vdev) > > mutex_lock(&virtio_9p_lock); > > list_add_tail(&chan->chan_list, &virtio_chan_list); > > mutex_unlock(&virtio_9p_lock); > > + > > + /* Let udev rules use the new mount_tag attribute. */ > > + kobject_uevent(&(vdev->dev.kobj), KOBJ_CHANGE); > > Ick, this is due to the sysfs file being added to the device after udev > was told the device was present. > > I'm working on cleaning all of this up, to keep stuff like this from > happening in the first place, by creating all of the needed files before > userspace is told about the object, but it's a long slog, and will take > a year or so to get it all right, the first pieces of this are going to > be showing up in 3.12 or .13 at the earliest. > > For now, I have no objection to this patch at all, especially as it > solves the problem for you. > > Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > [boo gmail, lets try this with plain text] Hey Greg, this patch was merged into 3.12 but would be useful for 3.10 and 3.11 :) http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e0d6cb9cd3a3ac8a3b8e5b22b83c4f8619786f22 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html