What is dahdi.auto_assign_spans and why should you care?

In later versions the kernel module dahdi[Q] includes a new parameter:
auto_assign_spans. It defaults to 1, and if you set it to 0, DAHDI can start behaving in strange and completely expected ways. Chances are the default will be set to 1 in a future version. Here is why you’ll want to set it yourself.

Up until DAHDI 2.5, hardware drivers for DAHDI presented DAHDI with spans[W]. The device would initialize the hardware, identify the spans in it, and register them with the dahdi core. The dahdi core assigns each span the first available span number and the first available series of channel numbers.

If you have a single device, what you get here is expected. If you have more than one device, you should make sure that they get detected in the same order on each boot. One missing: your configuration is completely botched. As a result, chan_dahdi has adapted to assume that if any channel has the wrong signalling, it may be because a device is missing (or got added) and we cannot trust other parts of the configuration.

Much work has been done to fix this fundemental problem. Dahdi 2.6 added the basic building blocks: When the hardware drivers register with DAHDI
they expose information about the complete device. This information is available to userspace through sysfs[E]. If the module parameter auto_assign_spans has the value 1 (the default), it all happens as before (except now we call the operation “assignment” – spans are assigned. And they can be unassigned and reassgined later).

But if auto_assign_spans is set to 0, the spans of the device will just sit there and wait for the user to do something: you can ask dahdi to either assign spans “automatically” (to the first available numbers, just as before). But you can also ask DAHDI to give each span a specific span number and a specific initial channel number. See [R] for the exact details.

While doing that we noticed that setting a span to be either E1 or T1
has to be done before it is assigned (you can’t change the number of channels after a span is assigned). Thus a similar interface was added to change the “span type”.

Another important component are “udev events” – when a kernel object is created (or destroyed), the kernel emits an event. udevd listens on those events. With the proper udev rules, you can react to addition of dahdi devices, spans or channels.

With those low-level tools in place, all we need are a few shell scripts. You can find the full specification in [T]. You should note the two new tools. Those tools provide a simple and clean interface to the sysfs interface.

dahdi_span_assignments: can unassign spans (remove) assign spans automatically (auto), or assign them according to the specifications in
/etc/dahdi/assigned-spans.conf (add). It also has the option
‘dumpconfig’ to print the current state in the same format used by its configuration file assigned-spans.conf .

dahdi_span_types: similar for the span types attribute with
/etc/dahdi/span-types.conf .

HOWTO
—