exporting CARD_INFO_GET to user space
md at Linux.IT
Tue Feb 22 12:27:34 EST 2005
On Feb 22, Roman Kagan <rkagan at mail.ru> wrote:
> 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.
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.
> 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)?
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.
> 2) which userspace interface is the most convenient (sysfs, proc,
/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.
> 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?
Every time you are in doubt if some code should go in the kernel or in a
user space tool then you should ask yourself to justify its presence in
the kernel. If you can't, then it's an user space task.
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.
(BTW, I remember somebody talking about OAM: AFAIK no kernel patches are
needed, the linux-atm CVS has an user space OAM daemon.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.infradead.org/pipermail/usbatm/attachments/20050222/ce52f19d/attachment.bin
More information about the Usbatm