Ticket #593 (new defect)
Opened 3 years ago
Consistent handling of fatal low-level modem-related errors
|Reported by:||PaulFertser||Owned by:||mickey|
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
Note: See TracTickets for help on using tickets.