On Fri, Aug 19, 2011 at 6:52 PM, Dan Williams <[email protected]> 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 > >
_______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
