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>
* Now we can limit fxotune "set" mode to specific channel range.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Sanitize hardware_id/location attributes, just like span_assignments
* Allow control of keys via SPAN_ASSIGNMENTS_KEY or '-k <key>' option
* In general, import most features/options from span_assignments
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Update dahdi.rules to create again the old fashioned device files
(/dev/dahdi/<channo>), but as symlinks to modern names.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
pinned-spans utilities are now essential:
* Called by udev rules
* Called by dahdi_genconf
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Correctly use the new "location" attribute
* Document the possibility to match against sysfs devpath
(used to be the "location")
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Install them as *.conf.sample -- that's what they are
* Correctly rename spantype.conf to span-types.conf (new name)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If you installed dahdi tools and did not specify DAHDI_PINNED=yes on the
makefile, when you run dahdi_genconf you would get an error like the following:
# dahdi_genconf
sh: span_types: command not found
Command failed (status=32512): 'span_types dumpconfig > /etc/dahdi/span-types.conf' at ...
This change allows the generator for span-types.conf and span-assignements.conf
check for the existence of the utilities before attempting to call them.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* If xpp.dahdi_autoreg parameter is 'Y' -- Skip actuall registration.
* If dahdi.auto_assign_spans is '0' and there's no /etc/dahdi/pinned-spans.conf
Than use 'span_assignments auto ...' to assign device spans.
* Since dahdi_registration iterate in correct xpp_order, the span
assignment logic provides migration path for users who did not
generate their pinned-spans.conf configuration yet.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* New functionality (documented in the script header):
- Alternative "keys" for device matching
- Added new command line options: --help, --dry-run, --verbose, --key
* Clean sysfs attribute contents from special characters in every use-case.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Do the "right thing" (hopefully. At least for a system with a single
device) if there is are no configuration files:
* No span-types.conf: just ignore it as before. It is optional.
* No pinned-spans.conf: use span_assignments auto (same as having
dahdi.auto_assign_spans=1).
* No system.conf: generate a temporary one with dahdi_genconf.
This will hopefully allow having a partially-working system, and help
making ut usable with 'span_assignments dumpconfig'. Or maybe just work
as-is.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
