[asterisk-dev] dahdi sysfs branch

Tzafrir Cohen tzafrir.cohen at xorcom.com
Sat Dec 6 19:36:48 CST 2008


Hi

I've created a branch for dahdi improved sysfs interface. At the moemnt
it already implements some useful features and usable for other
developers to look at. It has most of the main features I wanted.
It is generally not intended for merge before 2.1.0 is released, as it
is a major change.

The branch:
http://svn.digium.com/view/dahdi/linux/team/tzafrir/sysfs/
http://svn.digium.com/view/dahdi/linux/team/tzafrir/sysfs/?view=log

http://svn.digium.com/view/dahdi?view=rev&revision=5451 includes the
README changes. 

It implements:
* Decent representation of spans and channels in sysfs.
* Implements some extra attributes for every span.
* Allow custom driver-specific span attributes.

Major TODO list:
* Add some useful channel attributes.
* Tend to reference counting and such.
* Notifications to userspace (udev).
* Use the extra attributes in userspace.
  - e.g.: reimplement dahdi_scan
* A single naming convension.

SysFS is a virtual file system that exposes kernel objects. DAHDI knows
about channels and span, and this is why they should be shown - allow
getting information from them and applying some specific actions (sysfs
attributes can be read/write).


Summary of the changes: 

Both dahdi_span and dahdi_chan include a struct device item (span_device 
and chan_device. hmm... maybe just rename those to "device"). Helper
macros dav_to_span and dev_to_chan were added. They use the fact that
the device is included in the general struct, and hence container_of can
be used.

Most of the code was added in a new dahdi-sysfs.c file. We should see if
it is indeed a mostly self-contained module. So far it is. 

dahdi-sysfs.c is based mostly on Oron's xpp/xbus-sysfs.c . I also opted 
to keep using the extra printk macros (DBG(), SPAN_DBG(), CHAN_DBG()). 
Maybe they should be made lower-case? I believe that using them can be 
handy for other modules, and their definition should be moved to kernel.h .


I used the following wording in the README:

  The sysfs interface is still experimental and subject to changes.
  
  Alternative phrasing: The sysfs interface is subject to changes. You 
  are advised to use the published interfaces from dahdi-tools (e.g. the
  dahdi-perl modules) rather than access it directly.

The stable interface to provide is also a matter to consider. sysfs
exposes internal object. Those may change when the implementation
changes. What do we want to expose? When can it change?


One object type that seems to be missing is "the device that holds the
span". 
* As you can see in the README change, quite a few of the attributes are 
  described as "The span's device's <something>". 
* The "timing" parameter of the span line also refers to a priority 
  within the ports in the same device.

Would such an object be useful?


Drivers can register extra custom span attributes. This is done 
throu an extra span attribute that points to an array of attributes to
register for the span.

Defining an attribute currently requires some petty changes and has an
ugly ifdef for kernels older than 2.6.15 . I figure that such a case
would be left to rot as it won't get throughly tested and I wonder how
to further reduce the ifdef-ed parts there and how to avoid duplicating
too many thing in various drivers.


One thing I'd like to see is how this can be used to make span
initialization more automated. I would like to have a udev event sent on
span registration, which will (as one option) generate configuration for 
this span along, and configure it with dahdi_cfg . Naturally we can have
parameters that are span-specific. 

Further more, when we get a span we have a good idea who it is exactly: 
its type, the numbers of its channels, its location, etc. This would
allow configuring "all channels from an analog card to be FXS_KS", "all
channels have echo canceller MG2", and such.


BTW: as we have sometihng similar already implemented in xpp, you can 
find its documentation at
http://docs.tzafrir.org.il/dahdi-tools/README.Astribank.html#_sys_interface

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir



More information about the asterisk-dev mailing list