exporting CARD_INFO_GET to user space

Roman Kagan rkagan at mail.ru
Tue Feb 22 14:02:58 EST 2005


On Tue, Feb 22, 2005 at 06:27:34PM +0100, Marco d'Itri wrote:
> This is a sound design principle, but the data which I'm trying to
> access is Conexant-specific and I do not think that it's useful to make
> it more general.

Here are the parameters cxacru knows about:

enum cxacru_info_idx {
        CXINF_DOWNSTREAM_RATE,
        CXINF_UPSTREAM_RATE,
        CXINF_LINK_STATUS,
        CXINF_LINE_STATUS,
        CXINF_MAC_ADDRESS_HIGH,
        CXINF_MAC_ADDRESS_LOW,
        CXINF_UPSTREAM_SNR_MARGIN,
        CXINF_DOWNSTREAM_SNR_MARGIN,
        CXINF_UPSTREAM_ATTENUATION,
        CXINF_DOWNSTREAM_ATTENUATION,
        CXINF_TRANSMITTER_POWER,
        CXINF_UPSTREAM_BITS_PER_FRAME,
        CXINF_DOWNSTREAM_BITS_PER_FRAME,
        CXINF_STARTUP_ATTEMPTS,
        CXINF_UPSTREAM_CRC_ERRORS,
        CXINF_DOWNSTREAM_CRC_ERRORS,
        CXINF_UPSTREAM_FEC_ERRORS,
        CXINF_DOWNSTREAM_FEC_ERRORS,
        CXINF_UPSTREAM_HEC_ERRORS,
        CXINF_DOWNSTREAM_HEC_ERRORS,
        CXINF_LINE_STARTABLE,
        CXINF_MODULATION,
        CXINF_ADSL_HEADEND,
        CXINF_ADSL_HEADEND_ENVIRONMENT,
        CXINF_CONTROLLER_VERSION,
        /* dunno what the missing two mean */
        CXINF_MAX = 0x1c,
};

I wonder which of them are Conexant-specific...  Would be interesting to
know what info other modems provide.

> It's obviously possible to find a subset of parameters which are common
> to every driver and abstract access to them in usbatm, but I see two
> downsides with this approach: kernel space processing is not needed (see
> #4) and it would not support chipset-specific parameters which do not
> fit in the interface.

Unless different modems provide information which makes sense only in
their own context, I'd opt for a superset of the possible parameters,
and stub out those not available in a particluar driver.  E.g. not
all attributes for every device in /sys/class/net/* contain useful data,
but they are present there for uniformity.

> >  2) which userspace interface is the most convenient (sysfs, proc,
> >     ioctl)?
> /proc is not acceptable anymore for this kind of things and a IOCTL is
> hard to use (see cxioctl: you need usbdevfs, libusb and knowledge of the
> USB API), so sysfs is left.

Agreed.

> As I explained I do not think that trying to abstract the data is worth
> the effort, so I see no reason to process them in the driver.
> I think that the most convenient interface would be to just expose the
> raw data to userspace in a file (or at most as a set of numbers).
> A typical example of this are the /sys/devices/pci*/*/config files.
> This is a simple interface which does not bloat the driver and leaves
> all control to the user space tool.

PCI config data has a fairly well defined structure; here you suggest
that each driver exports something that will need a driver-specific tool
to parse it.  IMHO it doesn't make much sense: if you need to put the
chipset-specific knowledge in this tool, you can just add a couple of
libusb calls and fetch the required data directly from the modem via
usbfs.

To my taste a more convenient approach is to define a set of (numeric)
attributes worth knowing in userspace, with each attribute put into a
separate sysfs file, and let each driver fill in those it can.  Then the
userspace utility would be again driver-agnostic.  And I agree that
converting those numbers into strings is better done in userspace.

Cheers,
  Roman.



More information about the Usbatm mailing list