DeviceFS device disconnected woes.

Applications using SerialUSB open 2 files – one for reading (rx) and one for writing (tx). When you unplug a device/kill module, while the files are open, SerialUSB leaves the tx file open and you can no longer close it with !closefiles. It is always the tx file left open even though the application using serialusb attempts to close both. The order in which the application closes the files makes no difference the tx file is always left. Both file closures produce the ‘Device not found’ error which is the error you get when you shut down with this broken file.

This is the sequence of events:

1) An application opens SerialUSB for read and write and waits for input.
2)        USB device gets unplugged,
3)        USBDriver deregisters USB device from DeviceFS
4)                DeviceFS issues Service_DeviceDead USB "USB"
5)                        SerialUSB receives Service_DeviceDead and deregisters SerialUSB from DeviceFS
6)                                DeviceFS issues Service_DeviceDead SerialUSB "SerialUSB" - ignored
7)                                DeviceFS sends device call DeviceFS_Finalise 0 to serialusb
8)                                        SerialUSB closes all USB endpoints for device
9)                                DeviceFS issues Service_DeviceDead SerialUSB parent_dead (0) - ignored
10)                       SerialUSB deletes internal data
11)               DeviceFS issues Service_DeviceDead USB parent_dead - ignored
12)       USBDriver deletes internal data
13) Application closes SerialUSB files but fails

The application does not get a chance to close the files between 3 and 12

If I take SerialUSB out of the equation and instead make the application open rx and tx usb files directly, rmkilling usbdriver leaves an open tx device as SerialUSB. However if the device is disconnected instead, all files are closed. This appears to be good fortune rather than design as it is a consequence of the unplug notification from the USB device happening after a delay. This gives the application a chance to see the usb files fail with a ‘stalled’ error so can close the files before the usbdriver knows the device has been disconnected at which stage it deregisters the device with DeviceFS.

I think that the files need to be closed by the application at stage 6 but that can’t happen. SerialUSB doesn’t know the fileswitch file handle so can’t close the files itself and it can’t return control to the application. I could delay stage 5 with a CallAfter to give the application a chance to close but it’s only a bodge as it doesn’t solve reinit – it’s probably the best solution i have.

I’ve run out of ideas so I’ve posted this in the hope that I’m completely wrong and it’s obvious to someone that there is a solution.

I’ve found a solution that is looking good at the moment. At stage 5 before deregistering the SerialUSB device from DeviceFS I’ve iterated through all the fileswitch file handles with OS_FSControl 21 matching the filing_system_file_handle to the device’s filing_system_file_handle then closed the file with OS_Find. So unless something shows up in testing I can now reinit the SerialUSB module or unplug a device while a device file is open.

Its a bodge but beggars can’t be choosers.