Consistent handling of fatal low-level modem-related errors

[PaulFertser]

16:32 < PaulFertser> mickeyl: ... fsogsmd closing modem completely on timeout.
16:32 < mickeyl> right
16:32 < mickeyl> what is your preferred behaviour?
16:33 < mickeyl> lets say we try to send a command to the modem
16:33 < mickeyl> it doesn't respond
16:33 < mickeyl> what shall we do?
16:33 < mickeyl> i think closing the modem is the right way
16:33 < mickeyl> i tried all kinds of things beforehand
16:34 < mickeyl> but eventually they all lead to the conclusion that
16:34 < mickeyl> once the modem is stuck, it's best to close it and reopen
16:34 < mickeyl> now the problem is how to deal with this wrt. to the upper layers
16:34 < mickeyl> how about sending a 'ResourceVanish' signal?
16:34 < mickeyl> and have the upper layers rerequest the modem?
16:34 < PaulFertser> mickeyl: i most probably would prefer the daemon to try as hard as it can to maintain the status quo, and 
                     here i'd probably prefer it to automatically close the modem, open it, and after it's ready to go to the 
                     "functionality" it was in before the failure.
16:36 < PaulFertser> mickeyl: what you propose would mean my UI should listen to those signals and care about it, i do not 
                     feel it being right, maintaining hardware in a consistent state is not the UI task.
16:36 < mickeyl> not necessarily the UI
16:37 < PaulFertser> mickeyl: who else knows about the last requested "set gsm functionality"?
16:37 < mickeyl> the communication agent, which often is a layer in between the UI and fsogsmd
16:37 < mickeyl> for SHR, it's phonefsod
16:38 < PaulFertser> mickeyl: i somehow do not feel like using it with FSO.
16:38 < mickeyl> yep and it shouldn't be a necessity