From: Marcel Holtmann <marcel@holtmann.org>
To: ofono@ofono.org
Subject: Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings
Date: Tue, 04 Jan 2011 00:05:05 -0800 [thread overview]
Message-ID: <1294128305.5852.72.camel@aeonflux> (raw)
In-Reply-To: <1294125223.8212.59.camel@jsaunama-desktop>
[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]
Hi Jukka,
> > thinking about this a bit more and with the background that there is
> > already an existing public database, we might should just enable a
> > provision driver inside the oFono core.
> >
> > Meaning that we can have multiple implementations of different databases
> > with just different priorities. Each nicely separated in their own
> > plugin and we don't bother the oFono core with where to get the data
> > from. So my idea would be that the oFono core just asks to provision a
> > new context. If a plugin feels responsible, then it does so. If not then
> > it stays empty.
> >
> > Running oFono on the desktop/netbook etc. it makes sense to use the
> > current mobile broadband provider database. However on a phone that is a
> > not so good database. And for you guys it would also be possible to
> > continue using a CSV based format.
>
> This sounds very good to me. Making provisioning modular makes a lot of
> sense.
>
> But I am not yet very familiar with oFono plugin architecture. Is there
> some pattern in oFono code I could follow when implementing this, or
> could you or someone provide some skeleton code how this should go?
>
> In my patch (3/4) for gprs.c, I call get_operator_settings() (in
> operator-settings.c), which returns list of gprs_access_settings, that
> are then created as contexts. I assume now this get_operator_settings()
> would somehow call registered provisioning modules, that similarly would
> return list of gprs_access_settings? Or should these plugins directly
> call some new gprs atom interface to create the contexts?
the oFono plugins work like kernel modules. They are pretty much
generic. Inside the init function you can a driver register function and
inside the exit function, you call the driver unregister function.
We need to discuss some more details here, but something along these
lines should do it:
struct ofono_gprs_provision_driver {
const char *name,
int priorty,
int (*setup_context) (struct ofono_gprs_primary_context *context),
};
int ofono_gprs_provision_driver_register(const struct ofono_gprs_provision_driver *);
void ofono_gprs_provision_driver_unregister(const struct ofono_gprs_provision_driver *);
I am not 100% sure about the naming here, but something along these
lines seems to be the way to go.
Then your specific plugin would look like this:
static int setup_context(struct ofono_gprs_primary_context *context)
{
...
return 0;
}
static const ofono_gprs_provision_driver driver {
.name = "test",
.setup_context = setup_context,
};
static int plugin_init(void)
{
return ofono_gprs_provision_driver_register(&driver);
}
static void plugin_exit(void)
{
ofono_gprs_provision_driver_unregister(&driver);
}
OFONO_PLUGIN_DEFINE(myplugin, "My provision plugin", VERSION,
OFONO_PLUGIN_PRIORITY_DEFAULT, plugin_init, plugin_exit)
Regards
Marcel
next prev parent reply other threads:[~2011-01-04 8:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-03 7:31 [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings Jukka Saunamaki
2011-01-03 7:31 ` [RFC PATCHv2 1/4] sim: add ofono_sim_get_mnc_length Jukka Saunamaki
2011-01-03 20:37 ` Marcel Holtmann
2011-01-03 7:31 ` [RFC PATCHv2 2/4] operator-settings: Add GPRS context provisioning sources Jukka Saunamaki
2011-01-03 7:31 ` [RFC PATCHv2 3/4] gprs: add automatic context settings provisioning Jukka Saunamaki
2011-01-03 7:31 ` [RFC PATCHv2 4/4] operator-settings: Example GPRS context settings file Jukka Saunamaki
2011-01-03 8:57 ` [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings Kalle Valo
2011-01-03 10:44 ` Jukka Saunamaki
2011-01-03 11:40 ` Kalle Valo
2011-01-03 13:32 ` Aki Niemi
2011-01-03 13:38 ` Jukka Saunamaki
2011-01-03 20:34 ` Marcel Holtmann
2011-01-03 11:28 ` Aki Niemi
2011-01-03 20:31 ` Marcel Holtmann
2011-01-03 23:03 ` Marcel Holtmann
2011-01-04 7:13 ` Jukka Saunamaki
2011-01-04 8:05 ` Marcel Holtmann [this message]
2011-01-04 8:42 ` Jukka Saunamaki
2011-01-04 9:29 ` Marcel Holtmann
2011-01-04 8:23 ` Kalle Valo
2011-01-04 8:30 ` Marcel Holtmann
2011-01-04 10:00 ` Kalle Valo
2011-01-11 0:59 ` Marcel Holtmann
2011-01-13 22:41 ` Kalle Valo
-- strict thread matches above, loose matches on Subject: below --
2011-09-08 7:38 manju krishna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1294128305.5852.72.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox