[asterisk-dev] dahdi sysfs again

[Tzafrir Cohen]

Hi

An update on DAHDI sysfs:

(I tried to make this a code reiview, but reiviewboard doesn't even give
me an error)

I'm working on sysfs support in DAHDI. The code is in the branches (one
for linux/ and one for tools/ )

  http://svn.digium.com/svn/dahdi/linux/team/tzafrir/sysfs/
  http://svn.digium.com/svn/dahdi/tools/team/tzafrir/sysfs/

At the moement sysfs already provides useful information about spans and
channels. It also sends an event to userspace when a span is ready (and
when a span has been removed).

In DAHDI-tools I started reimplementing dahdi-perl to get all the
information from sysfs. This should only change the implementation and
not the interface.

In dahdi-linux the code mostly resides in two new source files.
dahdi-base.c seems to be getting a bit large and I had mostly
independent modules. Those files are dahdi-sysfs.c and the simpler
dahdi-sysfs-chan.c .

Interesting stuff:

* No need for dedicated tools to get information about spans and
  channels. Just read the files under sysfs.
  - What information do we actually want to expose there?
  - At the moment I expose too many things as numbers rather than as
    meaningful names (e.g.: alarm types, signalling and sigcap).
  - At the moment all attributes are read-only. This also helps avoiding
    locking issues.

* Configure a span when it is generated:
  http://svn.digium.com/svn/dahdi/linux/team/tzafrir/sysfs/drivers/dahdi/span_hook.sample
  This is a script that is intended to be called from udev. 
  As you can see, it provides a better implementation of the 'ztcfg'
  post insmod call. It can merely run dahdi_cfg . But can also run
  dahdi_cfg for this span alone (using simple templating) and can also
  use some auto-configuration.

  - Can all items in dahdi_cfg be configured in separate per-span calls?
    Specifically 56k can't: If it is not explicitly set on a channel, it
    is implecitly set to 64k.

* printk macros. Those generally belong in kernel.h, but in order to
  reduce the impact I for the mement left them (duplicated) at both
  dahdi-sysfs.c and dahdi-sysfs-chan.c . Those macros do two things:

    DEBUG(<type>, "message" ...);

  Which replaces:

    if (debug & DEBUG_<type>) 
      printk(KERN_DEBUG "message", ...);

  Another thing is the {DEBUG|INFO|NOTICE|WARNING|ERR}_{SPAN|CHAN}
  The idea is that if we are already in a context of a well-known span of
  channel and we print a message, that message should include the name
  of the span or channel. 

  - Macro names should probably be set to lower case.
  - How does this work with the existing module_printk ?

This is independently of the main functionality of the branch.


Missing Stuff:
-------------

Pseudo Channels:
Should they reside under some "pseudo span"?



Driver representation in sysfs:
This is currently missing. While all spans are in a "spans" bus, they
are also handled by a single, dummy driver. This fits the way DAHDI
works, but it also means that we don't really know what driver has
created the span.

I figure that without proper driver kobject, decent reference counting
(#10601) will not work. The way to go here may be that the dahdi_span
struct may include an optional driver pointer.


Real Devices:
Currently we put all the spans as devices under a single root in the
devices tree (/sys/devices/dahdi ) rather then include them in the
proper device tree (e.g.: a PCI device: under /proc/devices/pci ).
Currently only the Astribank driver has a separate representation for
its own device (at least among the drivers in the DAHDI tree).

While I can't think of a specific immediate reason why this should be
needed, the information regarding PCI devices is duplicated too much at
the moment in the span itself.


Dynamic Spans:
Not really sure how this works with them.


Asterisk and co.:
So we know how to make a newly-generated span Just Work. But what about
Asterisk?

At the moment chan_dahdi's initialization is an all-or-nothing: if there
was but one error, everything is down. This is because the numbering is
global. If we had a less global addressing we might have been able to
configure separate channels independently. And maybe even configure new
spans at run-time.

-- 
               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