[asterisk-dev] A plan for span

[Shaun Ruffell]

Kevin P. Fleming wrote:
> Shaun Ruffell wrote:
> 
>> 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 are 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.
> 
> In previous versions of this discussion (months ago), we considered that
> option, and discarded it because it requires configuration and things to
> happen 'at the right time', and it doesn't work for devices that can be
> added after boot time (Xorcom's Astribank devices, dynamic spans created
> with dahdi_dynamic_eth or dahdi_dynamic_loc, hotplug PCI, etc.).

It's not ideal, but I still think it would be less risky / easier to implement 
especially since Xorcomm is already doing something similar.  My assumption 
(perhaps wrong) is that Asterisk itself cannot handle dynamic arrival and 
removal of dahdi spans.  If this is so, as long as the registration utility is 
told which unique devices to wait for, and it waits for them all to present 
themselves to register in order it would solve many of the existing issues, 
while not requiring nearly as many changes.

Now, if we want to be able to walk up to a production asterisk system and just 
plug in a new span or two and have it work....no....this won't cut it.  Also if 
want Asterisk to be able to operate under conditions where devices may or may 
not be there at any time....would need more thought, but I didn't think that 
was a goal?

> 
> Using the existing hotplug mechanism to provide symbolic names to spans
> and devices both solves the load ordering issue and also provides much
> more understandable configuration and usage syntax. It also avoids a 250
> channel limit, as we no longer have to have any specific major or minor
> numbers for channels, they can be totally dynamic.

I agree this would be better...but this is orders of magnitudes more complex. 
Everything that refers to zap channels by a number would need to change, 
dialplans, management scripts, call files, GUIS, etc..