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>
This fixes a confusing error message. When sem_open failed, the system.conf line
number was being printed and the system error code was not.
Signed-off-by: Shaun Ruffell <sruffell@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>
auto_spans and dahdi_cfg -c are valid config methods which may not have a
/etc/dahdi/system.conf. We already check for the existance of the dahdi modules
before the case start, so I think it's safe to remove this section.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Fixes a regression introduced in
3572bb5a13 (before 2.7.0) - most of the
dahdi_perl tools will fail for an Astribank with no modules claiming
"No XPDs for '/sys/bus/astribanks/devices/xbus-00'"
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Don't warn when a sysfs attribute does not exist.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Russ Meyerriecks <rmeyerriecks@digium.com>
* Add '--line-mode=<E1|T1|J1>' option to dahdi_span_types:
- Will first generate a wildcard entry (* *:<type>)
- All later entries will be commented-out.
- Manually uncommenting any of them will create an "override"
(e.g: mixed system with all spans T1, but some E1)
* Now dahdi_genconf does not generate span-types.conf by default:
- Added '--line-mode=<E1|T1|J1>' option to trigger generation
- This parameter will be passed to "dahdi_span_types dumpconfig"
- Also explicit specification of 'spantypes' as an argument will
trigger a similar generation (with a default of 'E1').
- The line-mode may also be passed to the generator directly
with identical results. Example:
dahdi_genconf spantypes=line-mode=T1
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Russ Meyerriecks <rmeyerriecks@digium.com>
* Allow wildcards for both device and span number (as before).
Example:
* *:T1
* But now we are carefull to follow strict order in the configuration
file. This means, if there are multiple matches -- last one wins.
* So we can use specialisation:
* *:T1 # Everything is T1
FOO [34]:T1 # Except spans 3,4 on the FOO device
* Added --dry-run and --verbose options.
* Updated the man-page:
- Fixed "registered" => "assigned".
- Use "line mode" for E1/J1/T1.
- Document current changes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Russ Meyerriecks <rmeyerriecks@digium.com>
* Use the term "assignment" instead of "registration" (for spans).
* Further fixes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Russ Meyerriecks <rmeyerriecks@digium.com>
* 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>
* 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>
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>
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>
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>
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>
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>
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>
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>
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>
Acked-by: Oron Peled <oron.peled@xorcom.com>
When auto span assignment is disabled, it's possible that simply running
# /etc/init.d/dahdi restart
Will fail since dahdi_cfg can run in parallel with udev scripts that are
assigning spans, which results in /etc/dahdi/system.conf describing spans that
do not exist in the system.
This change sets up dahdi_cfg, when run without the -C or -S options, to look in
sysfs and make sure all spans for each device are assigned. dahdi_cfg will wait
5 seconds for span assignment to happen before proceeding normally.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes a regression in 2.8 (ffced0ca) in the main Makefile:
MAN_PAGES gets assigned twice and thus most man pages will not get
installed.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The environment variables that specified the full path the the configuration
files for dahdi_span_types and dahdi_span_assignments was documented, but they
were not actually set from the environment.
Also, the case of the variable was changed to match the one for the directory
where the rest of the config files are located.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
All new dahdi tools and utilities will be prefixed with "dahdi_" in order to
avoid any future conflicts with other packages.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
If a configuration file was specified that used the devpath, like:
# Device: [] @Board_ID_Switch_0 /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/pci:0000:02:08.0
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/pci:0000:02:08.0 1:E1
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/pci:0000:02:08.0 2:E1
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/pci:0000:02:08.0 3:E1
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/pci:0000:02:08.0 4:E1
Then the span_types script would silently fail to match the configuration lines
for the device and silently fail to change the linemodes.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
The xpp_sync will fail if there are not any Astribank devices loaded. Check for
existence of the tools before trying to sync.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Include pinned-spans.conf and span-types.conf in the generated
README.html. Reformat them to render properly.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
