Re: ModemManager API review

[Marcel Holtmann <marcel holtmann org>]

Hi Dan,

> > > > So the first thing that draw me off is that we are stupidly mapping
> > > > the HAL
> > > > devices 1:1 to our devices. That is wrong. We should not do this.
> > > > So for
> > > > example my Option card has three TTYs and one network device. This
> > > > all is
> > > > one device. Currently it shows up as three devices. The number of  
> > > > TTY
> > > > (control, data or whatever) is an implementation and should not be
> > > > exposed
> > > > via the API. So we have to be smart with this.
> > >
> > > With the generic implementation, MM maps a HAL device with
> > > "modem.command_sets" property as a single device. So if you got 3,  
> > > it
> > > means your HAL .fdi file is incorrect.
> >
> > I don't see how that can be. It was the HSO card and it might need
> > more tweaks than usual. Besides kernel patches ;)
>
> hso cards _do_ need more tweaks than usual.  They have either one or  
> two
> control ports, but the HAL magic here is somewhat lacking.  We need to
> "tag" the various ports with "control" or "data" or "gps" or  
> "control2"
> in addition to determining the command sets.  What you're seeing is  
> HAL
> not being able to tag the ports correctly, because the only way to  
> know
> this is to check hso-specific sysfs files.  We really need a generic  
> way
> to do this in the kernel drivers.

sounds like a good idea. Do you have any proposal for the generic way  
of tagging the "type" of a TTY. Or is just a todo item?

It might be a good idea to natively integrate this into the TTY  
subsystem instead of having every driver to create sysfs files manually.

> What _should_ be happening here is that (once Kay creates the repo)  
> that
> a udev prober checks out each serial port's supported command sets,  
> and
> stores that info in the udev database.  Then, either MM can read that
> information directly, or we create a small HAL callout that reads the
> udev database and adds the right modem.command_sets items for  
> backwards
> compatibility.  Then we kill 10-modem.fdi and everyone is happy.

I am all for the udev way. Was just checking out Kay's work in libudev  
and that looks really promising.

> In short, 'hso' is special and HAL is missing some stuff.  It's not
> really MM's fault.

Fair enough. So I am going to see if we can fix HAL somehow to  
classify my HSO device correctly.

I also have one of these new Novatel MC950D from Rogers in Canada that  
is not recognized by HAL as a GSM modem.

Regards

Marcel