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?
Regards
Marcel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
