Messages in this thread | | | Subject | Re: Implement class_device_update_dev() function | From | Kay Sievers <> | Date | Sat, 08 Jul 2006 02:26:37 +0200 |
| |
On Fri, 2006-07-07 at 09:42 +0200, Marcel Holtmann wrote: > Hi Greg, > > > > for the Bluetooth subsystem integration into the driver model it is > > > required that we can update the device of a class device at any time. > > > > You can? Ick. > > > > That messes with my "get rid of struct class_device" plans a bit... > > this must not be a class device, but at the moment TTY, network and > input are still class devices. The Bluetooth subsystem moved away from > using class devices. > > > > For the RFCOMM TTY device for example we create the TTY device and only > > > when it got opened we create the Bluetooth connection. Once this new > > > connection has been created we have a device to attach to the class > > > device of the TTY. > > > > > > I came up with the attached patch and it worked fine with the Bluetooth > > > RFCOMM layer. > > > > 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?
Thanks, Kay
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |