dahdi_handle_device, dahdi_span_config: Check for auto_assign_spans only when ACTION is add.

When dahdi.ko is unloaded, it may be possible for the driver to be removed from
the kernel before the udev scripts are run.  When this happens, you'll see
messages like the following which are not accurate:

    'dahdi_handle_device'[24567]: Old driver (no auto_assign_spans parameter). Skip /devices/pci0000:00/0000:00:1e.0/0000:11:01.0/pci:0000:11:01.0

Now instead you will see:

    'dahdi_handle_device'[28008]: remove: /devices/pci0000:00/0000:00:1e.0/0000:11:01.0/pci:0000:11:01.0

Also, all the udev events will be logged in the system log even when they are
ignored because of legacy auto span assignment. This will help show what is
going on during the transition period to full udev configuration of spans.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
span_types/assignments: no * in device list

If there are no dahdi devices, $devbase/* expans to have a literal '*',
which leads to warnings such as:
/usr/sbin/dahdi_span_types: 1: cd: can't cd to /sys/bus/dahdi_devices/devices/*

Let's just avoid those.

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi_genconf: don't generate spantypes by default

A sane value for span-types.conf is either "all E1" or "all T1". Either
way it is not hardware-dependent, and hence no point in regenerating on
when the hardware changes.

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi_genconf: Add 'modules', 'spantypes', and 'assignedspans' to list of available generators.

This is a documentation change, that hopefully will help until I can remember
the names of the new generators.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi_span_types: Show location of configuration file in help message.

Makes similar in for the dahdi_span_assignments in that the location of the
default configuration file is shown in the help screen.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi_handle_device: Auto assign only the device being added.

Eliminates trying to add spans multiple times as seen below:

    'dahdi_handle_device'[21993]: add: /devices/dynamic:loc:1
    'dahdi_handle_device'[21991]: add: /devices/dynamic:loc:0
    'dahdi_handle_device'[22001]: auto-assign /sys/bus/dahdi_devices/devices/dynamic:loc:0
    'dahdi_handle_device'[22001]: auto-assign /sys/bus/dahdi_devices/devices/dynamic:loc:1
    'dahdi_handle_device'[21999]: auto-assign /sys/bus/dahdi_devices/devices/dynamic:loc:0
    'dahdi_handle_device'[21999]: auto-assign /sys/bus/dahdi_devices/devices/dynamic:loc:1
    kernel: [ 3348.312534] dahdi_devices dynamic:loc:0: local span 1 is already assigned span 1
    kernel: [ 3348.312552] dahdi_devices dynamic:loc:1: local span 1 is already assigned span 2

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi_cfg: Add semaphore to prevent parallel execution.

When dahdi is configured for fully dynamic configuration on a device and
span basis via sysfs and udev it is possible for multiple instances of
dahdi_cfg to be run in parallel on different spans. If this happens it
is possible to see errors on the console that tone zones are already
registered since the check for the existence of a tone zone and the
re-registering needs to be atomic.

dahdi_cfg will now prevent itself from running in parallel.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
dahdi_cfg: Allow dynamic spans to handle udev based span assignment.

Prior to this commit, if auto_assign_spans was set to 0, it was possible to
get in an endless loop creating and destroying spans. The primary reason was
that all dynamic spans are destroyed and recreated each time dahdi_cfg runs, BUT
dahdi_cfg was run each time a new span showed up in udev when auto_assign_spans
was set to 0.

Now dahdi_cfg will only destroy and recreate dynamic spans if dahdi_cfg is run
without a specifc span number. Also, while creating dynamic spans, dahdi_cfg
will pause for up to one second for the span to be assigned in order to ensure
that the spans are numbered consistently when auto span assignment is
configured.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wcte13xp: Teach tools about te131 te132 products

Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
hotplug modularization: move sources to a subdir

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
hotplug modularization: split logic to scriptlets

* Device related operations are ordered in /usr/share/dahdi/handle_device.d/
* Span related operations are ordered in /usr/share/dahdi/span_config.d/
* In the future, span_config.d/50-asterisk should be moved to Asterisk.

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
new "dahdi_waitfor_span_assignments" tool

* Allows waiting until all spans are "assigned" or "unassigned"
* Current implementation use a polling loop with sleep
* Future implementation may block on sysfs attribute
  (like waitfor_xpds is blocking on sysfs Astribanks attribute)

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>