> Why do you want to expose STK activated contexts over D-Bus and
> deal with the consequences of this decision? Having oFono handle them
> completely internally would simplify the design quite a bit, no?
Yes, indeed. I thought that the PDP context created by and for oFono
should be however visible from outside. But I agree,
STK PDP context should not be handled from outside. So, I will remove
the D-BUS interface registration for this kind of context.
Should I also consider to not add this context to the gprs->contexts list?
I don't know yet ;)
As you can see, I'm using a callback to notify the STK atom when the
context is activated. Since the context is no more subject to D-BUS
handling, do you think I could map this callback directly as the
callback for the gprs_context driver (id
ofono_stk_activate_pdp_context_cb = ofono_gprs_context_cb_t)?
It implies that I need to setup the interface directly in the STK atom
but so far, I don't know if you agree with the modifications I did in
gprs.c regarding how this interface is updated when this is linked to a
STK PDP context (particularly for the host route).
Perhaps, even if it duplicates some code, you would prefer to see the
STK atom updating the interface directly?
Do not do that. I suggest you look into how STK Send SMS is implemented
and model this somewhat after that. GPRS atom needs to manage the
contexts and provide private API for activating 'hidden' ones.