Re: [Patch -mm 2/5] driver core: Introduce device_move(): move a device to a new parent.

["Kay Sievers" <kay.sievers@vrfy.org>]

On 11/15/06, Cornelia Huck <cornelia.huck@de.ibm.com> wrote:
> On Tue, 14 Nov 2006 22:50:52 -0800,
> Greg KH <greg@kroah.com> wrote:
>
> > On Tue, Nov 14, 2006 at 11:32:08AM +0100, Cornelia Huck wrote:
> > > From: Cornelia Huck <cornelia.huck@de.ibm.com>
> > >
> > > Provide a function device_move() to move a device to a new parent device. Add
> > > auxilliary functions kobject_move() and sysfs_move_dir().
> >
> > At first glance, this looks sane, but for the kobject_move function, we
> > are not notifying userspace that something has changed here.
> >
> > Is that ok?
> >
> > How will udev and HAL handle something like this without being told
> > about it?  When the device eventually goes away, I think they will be
> > very confused.

Yes, userspace will get confused, if we we don't get proper
notification. We require to update the udev and HAL database with the
new devpath, to find the current device context on device events, or
for "remove".

> Hm. I don't think we want to trigger udev with some remove/add events
> (especially since it is still the same device, it just has been moved
> around). A change event doesn't sound quite right either. But I guess
> we need to do something, at least to make HAL happy since it remembers
> the path in sysfs (although I seem to remember a HAL patch that got rid
> of it?)

Udev and HAL, both will need an event for the moving, with the old
DEVPATH value in the environment. We want something like a "rename" or
"move" event. Without that, weird things will happen in userspace,
because the devpath is used as the key to the device during the whole
device lifetime. The only weird exception today is the netif rename
case, which is already handled by special code in udev.

Thanks,
Kay