Moving libqmi-glib to fd.o's libqmi repo

Marcel Holtmann marcel at holtmann.org
Sun Jul 1 23:35:15 PDT 2012


Hi Aleksander,

> > I looked deeply into all areas of QMI services. Trying to create a fully
> > bloated library with API support for all services is a waste of time. At
> > least for oFono it is useless. The problem is that QMI itself is deeply
> > service context sensitive and there is no point in creating another
> > abstraction on top of it. I decided to just put the service specific
> > handling directly into the oFono drivers. Have a look at the code for
> > yourself, it worked out super nicely for us.
> 
> Sure it did, but we really want to have a library here, instead of 
> having everyone implement the message-specific logic over and over.

I am still failing to see what this all buys you. You still need to
understand what message input and output is available/required. You are
just getting fancy accessor methods. And these come at the price of a
larger binary size. If you look at QMI as something besides DMS and WDS,
it is pretty large API.

And a small side note; so for QMI it has to be a library that is suppose
to do everything. For AT commands it is then fine to redo things over
and over again and use resource intensive regular expressions.

How many users of this library are you actually expecting? Since the QMI
device exposed by the kernel can only be opened by one user at a time.

Regards

Marcel




More information about the libqmi-devel mailing list