exporting CARD_INFO_GET to user space

Roman Kagan rkagan at mail.ru
Tue Feb 22 10:50:32 EST 2005


On Tue, Feb 22, 2005 at 01:57:03PM +0100, Marco d'Itri wrote:
> I'm working on a perl program to display the modem status obtained with
> the CARD_INFO_GET command. E.g. for my system it prints stuff like:
> 
> Line speed: 800/320 Kbps
> Link status: connected
> Line status: up
> Modulation: ITU-T G.992.1 (G.DMT)
> Upstream SNR margin (dB): 4.69
> Downstream SNR margin (dB): 5.37
> [...]
> 
> To do this, cxacru_poll_status() should be modified to store the modem
> answer in an instance-specific variable instead that in the current
> temporary buf[] array, and then the driver should make its content
> available from a file in sysfs. I know how to implement the first part,
> but I do not know enough kernel programming to manage sysfs... is
> anybody willing to help me implementing this?

I am :)  I've been meaning to do something like this, just didn't
consider it high priority.  Nevertheless I suggest to discuss first
which way to take.

One of the benefits of the usbatm approach is that all _routinely_ used
utilities and interfaces (as opposed to one-shot stuff like firmware
extraction) are uniform over the different modem types.  E.g. the steps
to establish an internet connection over the ADSL link are absolutely
agnostic of whether it is a SpeedTouch or an AccessRunner.

I think that the interface to report the modem status should be made as
uniform as possible too (and I suspect other modem types do provide this
kind of information as well), that's why I brought the issue to the
usbatm mailing list.  In this regard there seem to be the following
questions to decide:

 1) should it be a common interface only (i.e. each subdriver does it on
    its own following some convention), or a common implementaion (e.g.
    struct usbatm_data is extended to contain a standard set of
    attributes; the subdriver is supposed to fill them in, while the
    core takes care of exporting them to userspace)?

 2) which userspace interface is the most convenient (sysfs, proc,
    ioctl)?

 3) should the exported data go in a single piece (one sysfs/proc file,
    one ioctl) or multiple per-attribute pieces?
    
 4) should the data be converted to human-readable strings, or
    this should be left to the userspace utilities?

What do you think?

Cheers,
  Roman.



More information about the Usbatm mailing list