evdev+hal => Too many input devices.

[Brian Rogers]

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