Brian Rogers wrote: > Gabor Gombas wrote: > >> Hi, >> >> On Wed, Jul 22, 2009 at 02:45:32PM -0700, Brian Rogers wrote: >> >> >> >>> @@ -118,14 +113,16 @@ static void del_conn(struct work_struct *work) >>> if (!device_is_registered(&conn->dev)) >>> return; >>> >>> + /* wait for child devices to go away first */ >>> while (1) { >>> struct device *dev; >>> >>> - dev = device_find_child(&conn->dev, NULL, __match_tty); >>> + dev = device_find_child(&conn->dev, NULL, __match_any); >>> if (!dev) >>> break; >>> - device_move(dev, NULL, DPM_ORDER_DEV_LAST); >>> put_device(dev); >>> + >>> + msleep(100); >>> } >>> >>> device_del(&conn->dev); >>> >>> >> Won't this cause problems for rfcomm devices (again)? This code was added >> for the reason in the comment you've deleted: the rfcomm device can >> remain alive long after the connection is done, and it won't go away >> until you find & manually kill the process that holds the device open. >> > > The device_move action looked obsolete to me since the comment lead me > to believe that device_move was moving the device to the root of /sys. I > saw the input devices, which weren't being touched there, wind up in the > root on their own when the connection was deleted so I assumed that had > since become automatic. But now that I look at the device_move function, > it looks like moving to null actually deletes the device. > > In that case, it's probably best to just delete everything right there > and not wait for anything to close on its own. If that doesn't create > any problems, that's what I'll do. Thanks for bringing this up. >
OK, that didn't work. Calling device_move with a null new_parent works the way I initially thought it did. I don't like the idea of these things moving right before they are deleted, and neither does HAL since it still doesn't remove the input devices properly in this case. I think I'll go with the original strategy to ensure everything gets removed from the same place it was first added. And I might make it work without polling. The rfcomm and connection objects sticking around until some process exits shouldn't harm anything since I believe a new connection will be given a unique name to avoid a conflict. I'll be sure to check this. What went wrong if the rfcomm was still inside the connection when the connection was deleted? Brian _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg