Re: [PATCH 32/36] driver core: Introduce device_move(): move a device to a new parent.

Greg KH
2006-12-04T23:05:22Z

On Mon, Dec 04, 2006 at 10:15:03PM +0100, Marcel Holtmann wrote:
> Hi Greg,
>
> > > > Provide a function device_move() to move a device to a new parent device. Add
> > > > auxilliary functions kobject_move() and sysfs_move_dir().
> > > > kobject_move() generates a new uevent of type KOBJ_MOVE, containing the
> > > > previous path (DEVPATH_OLD) in addition to the usual values. For this, a new
> > > > interface kobject_uevent_env() is created that allows to add further
> > > > environmental data to the uevent at the kobject layer.
> > >
> > > has this one been tested? I don't get it working. I always get an EINVAL
> > > when trying to move the TTY device of a Bluetooth RFCOMM link around.
> >
> > I relied on Cornelia to test this. I think some s390 patches depend on
> > this change, right?
>
> my pre-condition is that the TTY device has no parent and then we move
> it to a Bluetooth ACL link as child. This however is not working or the
> TTY change to use device instead of class_device has broken something.

Hm, I don't think the class_device stuff has broken anything, but if you
think so, please let me know.

> > > And shouldn't device_move(dev, NULL) re-attach it to the virtual device
> > > tree instead of failing?
> >
> > Yes, that would be good to have.
>
> Cornelia, please fix this, because otherwise we can't detach a device
> from its parent. Storing the current virtual parent looks racy to me.

You can always restore the previous "virtual" parent from the
information given to you in the device itself. That is what the code
does when it first registers the device.

And yes, I too think it should be fixed.

thanks,

greg k-h