Maintains the original registration order as was before span
assignments. Should allow seemless trannsition to
dahdi.auto_assign_spans=0
* The idea:
- We stop handling in udev the case of missing
/etc/dahdi/assigned-spans.conf
- Instead we rely on "registration_time" dahdi_device attribute from
DAHDI-linux
- Then, we can sort the devices and assign their spans in
/etc/init.d/dahdi
* Mechanics:
- From /etc/init.d/dahdi, we run a new 'dahdi_auto_assign_compat'
script (after "waitfor_xpds" etc.)
- In this script we "auto" assign spans of non-Astribank devices
- In the end of the script we run "dahdi_registration" which
does the same for Astribank devices.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Original actions didn't care about remove (10-span-types, 20-span-assignments)
* But others need to know about removals too.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
auto_assign_spans is an int and may have legal values other than 1. It
is legal (though pointless) to use: modprobe dahdi auto_assign_spans=3.
Any value != 0 is true.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Removes a potentially confusing error message. This is a reapplication of
(4f259cd569 "dahdi_handle_device, dahdi_span_config: Check for
auto_assign_spans only when ACTION is add.") which appears to have been
accidentally removed when moving the hotplug scripts into a subdirectory.
From the original commit:
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>
This reapplies the change made in commit (6ed0adc08 "dahdi_span_config: Do not run auto
span configuration if spans are auto assigned.") which appears to have been
accidentally removed in (7f826a7d35 "hotplug modularization: split logic to
scriptlets").
To rationale from commit 6ed0adc08:
I have seen cases were users run:
# modprobe <driver>; dahdi_cfg -c <custom config file>
and the spans end up misconfigured because dahdi_span_assignments ends up
running, via udev, after the user configured the span the way it wanted.
dahdi_span_assignments now looks at auto_assign_spans module parameter on
dahdi.ko, like dahdi_handle_device already does, to determine if legacy or udev
based configuration is being done.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
A well-behaving distribution may choose not to install
span_config.d/50-asterisk as part of dahdi-tools, as it belongs in
asterisk. Still, it would be nice to be able to keep it as a documented
usage example. So just writ where this file needs to go and what it
does.
No other change: it is still installed by default.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* 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>
