From: Greg KH <greg@kroah.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Implement class_device_update_dev() function
Date: Tue, 11 Jul 2006 16:18:44 -0700 [thread overview]
Message-ID: <20060711231844.GE18973@kroah.com> (raw)
In-Reply-To: <1152258152.3693.8.camel@localhost>
On Fri, Jul 07, 2006 at 09:42:32AM +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.
So to start with, you have a class device with no attached "struct
device"? And then after opening the device node, you want to create the
symlink?
> Would reissuing the uevent of the class device help here?
Not really, because as you state, we aren't changing the class device
itself, and throwing another uevent for it would probably just confuse
userspace :)
thanks,
greg k-h
prev parent reply other threads:[~2006-07-11 23:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-06 22:59 Implement class_device_update_dev() function Marcel Holtmann
2006-07-06 23:57 ` Greg KH
2006-07-07 7:42 ` Marcel Holtmann
2006-07-08 0:26 ` Kay Sievers
2006-07-08 9:27 ` Marcel Holtmann
2006-07-08 13:00 ` Kay Sievers
2006-07-08 13:28 ` Marcel Holtmann
2006-07-08 17:27 ` Marcel Holtmann
2006-07-11 23:18 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060711231844.GE18973@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox