[asterisk-dev] A plan for span

[Shaun Ruffell]

Oron Peled wrote:
>>> Thoughts, comments, ideas, flames?
>> Another thought that wouldn't require any changes to chan_dahdi or
>> dahdi_cfg, just control the order that devices are registered with dahdi. 
>> This would't work if you had things that are constantly connected and
>> disconnected (where you might want to leave holes in the channel numbers
>> for certain devices), but otherwise, it would solve the problem of all your
>> channels being renumbered when you added a new device, and with the
>> problems of races when autoloading different modules at system start.
>>
>> For example, you could export an sysfs attribute (register) that when
>> written to, that driver will in order register all the spans it supports. 
>> Then the hotplug script or init script can wait until all the devices it's
>> been configured for a re loaded and have exported their names in sysfs, and
>> then instruct them to register with dahdi in the order that it wants.  So
>> when you add a new card to your system, you would also add it to the list
>> of devices to be registered.
>>
>> A thought...
> 
> Well, since we have hot-plugable devices (USB) we had to implement exactly
> this technique ~2.5 years ago when we started testing multiple Astribanks.
> 
> Because it was long ago, we implemented via /proc. Our drivers normally
> do not register with zaptel automatically. You can register/unregister
> during runtime (when asterisk closed channels) by writing 0 or 1 into
>    /proc/xpp/XBUS-nn/XPD-mm/zt_registered
> Reading from this "file" would output 0 (if not registered) or the span
> number (if registered).
> 
> We wrap this handling by the zt_registration (now dahdi_registration)
> perl script that can show the status (without arguments) or if run
> with on/off arguments register all Astribank spans (sorted by a
> deterministic order).
> 
> This hack only solve the non-deterministic hotplug/boot problem.
> It does not cover the case of adding a new device (which may sort
> between other existing devices). This would still cause total
> change to the dialplan.

If the registration utility only registers devices that are configured (and 
they have to be configured anyway in some form to work with asterisk), and if 
all devices that are dahdi compliant only registers themselves on command, 
adding a new device wouldn't cause any problems since it would never be 
registered until configured to do so and then presumably the administrator 
would add it to the end of the list of devices.

However, if a device is removed there could be a problem in that the 
registration utility wouldn't register later devices while waiting for the 
removed device to appear.  Although the end result wouldn't be too different 
from what exists currently...you still have to change the configuration files 
if you remove a device.

> 
> We thought about the "reserve-range" idea, but it's even worse hack
> as we really cannot be sure how much to reserve (think about a single
> Astribank with quad-PRI + 3*FXS(8-ports) + 6 I/O channels = 150 channels).
> It would also require big changes to dialplan generation rules for
> many outside tools (from our zapconf/dahdi_genconf scripts to freepbx
> and its ilk) -- better invest the time to solve it well.

Yes...this is probably better punted until everything is changes to not try to 
open /dev/dahdi/* to access the channels...