gsm modem daemon
vanous at penguin.cz
Wed Feb 10 11:46:36 CET 2010
NJ> > looking at the FSOSHRCON proposal, seems fsogsmd will still take
NJ> > some time befoe we see it in action ... :( , too bad for us who
NJ> > loose gsm after gprs...
NJ> True, but it's not fair to put extra pressure on Mickey...
Sorry if it sounded that way. i know Mickey did a huge job to push
fsogsmd before new year. I was hoping the gprs bug would go away with
fsogsmd but after trying i can see that the fsogsmd is not running plus
i get no replies on how to run it or what to do. Then i see the shr
implementation being planned for sometimes in summer. Again, i cannot
say more or less then "too bad for us suffering the issue".
NJ> And, even when fsogsmd is good for 80% stable operation, I'm sure it
NJ> will have its own new issues in non-mainline scenarios.
Not sure what you mean by non-mainline scenario. Another issues are
quite likely but we will cross that bridge when it comes.
NJ> Therefore, perhaps we should also continue looking in parallel at
NJ> the problem in ogsmd. It's well known by now (I think) that this is
NJ> something to do with the internals of the ProcessGuard object, which
NJ> uses Python's spawning and process monitoring primitives to manage a
NJ> pppd process, and that somehow that all goes wrong when pppd is
NJ> killed, causing frameworkd to hang. Would anyone be interested in
NJ> investigating this further?
IMHO no-one will spend their time as fso2 will replace it. i am lacking
the expertize to investigate but have wanted to give it a try.
From my understanding of the concept: "The python implementation is the
chance for getting the API right; the vala implementation is the chance
of getting the right API fast." i gather that the API is right but the
conditions are not perfect. So troubleshooting the good API in python is
a step back, checking the fast right API should be the priority.
More information about the Smartphones-userland