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