On Fri, Aug 19, 2011 at 6:52 PM, Dan Williams
<dcbw redhat com> wrote:
On Thu, 2011-08-04 at 13:36 -0400, ttuttle wrote:
> Hey folks,
>
> I'm working on 3G for Chromium OS, and I'm about to try to put
> together a patch to add the firmware selection interface to
> ModemManager. I've got a few questions:
Sorry for the lag, I was in Berlin for Desktop Summit for a week + right
after you sent this mail...
> 1. Should the interface definition go in introspection (presumably in
> the ModemManager namespace) or new (presumably in the ModemManager1
> namespace)? I'm under the impression that new/ is not yet in use, but
> we would hope to use the firmware interface fairly soon, so would
> putting it in new/ delay that?
I'd first put it into introspection/ and then fix up the versioning and
add a different copy to new/. That way we can cherry-pick/backport the
original one to 0.5 too.
> 2. I'd like to get rid of the distinction between installed and
> available firmwares. The only hitch is that, if we're using a device
> like the gobi3k (which stores up to 6 firmware images on the device),
> selecting a firmware on disk may cause one of the firmwares on the
> modem to be removed to make room, and we might not have a copy of that
> firmware to reinstall if we need it again. Personally, I am okay with
> the idea that either all firmwares need to fit on the modem, or we
> need to have backup copies of all firmwares the user might want to
> reinstall, but I realize that might not actually apply to all use
> cases. Do people have an opinion on this?
I'm not opposed to doing it like you suggest here and killing the
distinction, but perhaps we could create the API in a way that allows us
to add the distinction back later?
Despite the complexity, I think we should keep the distinction. We can allow clients to collapse the "installed" and "available" firmware before presenting to the user, or have a single call to retrieve both, as long as a 'bit' somewhere indicates the distinction.
> (My gut instinct on this is that we will want to keep the distinction,
> even though it makes things much more complicated.)
If you think it might be necessary in the future, then perhaps we do
just have to suck up the distinction. It's your call.
> 3. I'm not sure how much detail should go in the metadata of the
> firmware image -- are we expecting to provide just enough information
> that the user can pick one from a list, or enough information that a
> smart client of ModemManager might be able to switch firmware
> automatically to connect to a particular network?
Ideally we'd get MCC/MNC of the operator, an operator name, and the
capabilities bitfield (GSM, CDMA, LTE, etc) out of the firmware. A
bonus would be firmware version information for diagnostics. But yes,
we do want enough to be able to pick a specific operator's firmware if
we need to, based on user input or other data.
Agreed.
Thanks!
Dan
> (My gut instinct on this is that we will want enough information to
> pick a particular network.)
>
> Feedback greatly appreciated.
>
> Thanks,
>
> ttuttle
