Hi Kay,

> > > > > > But userspace should also find out about this change, and this patch
> > > > > > prevents that from happening.  What about just tearing down the class
> > > > > > device and creating a new one?  That way userspace knows about the new
> > > > > > linkage properly, and any device naming and permission issues can be
> > > > > > handled anew?
> > > > > 
> > > > > This won't work for Bluetooth. We create the TTY and its class device
> > > > > with tty_register_device() and then the device node is present. Then at
> > > > > some point later we open that device and the Bluetooth connection gets
> > > > > established. Only when the connection has been established we know the
> > > > > device that represents it. So tearing down the class device and creating
> > > > > a new one will screw up the application that is using this device node.
> > > > > 
> > > > > Would reissuing the uevent of the class device help here?
> > > > 
> > > > How about KOBJ_ONLINE/OFFLINE?
> > > 
> > > I am not that familiar with the internals of kobject. Can you give me an
> > > example on how to do that?
> > 
> > Just send another event (but not add or remove), for the already created
> > object. CPU hotplug uses ONLINE/OFFLINE, and we also use it to get
> > notified when the device mapper table is set up (not upstream). Udev is
> > able to update symlinks, or run actions on "online" events if asked
> > for. 
> 
> the attached patch sends ONLINE when a device has been attached to a
> class device and OFFLINE when it has been removed.

the order of ADD and ONLINE was wrong in some situations and also uevent
forgot to send out the extra ONLINE when a device is attached. The
attached patch fixes all this stuff. Any comments?

Regards

Marcel