[asterisk-dev] A plan for span

[Shaun Ruffell]

Tzafrir Cohen wrote:
> On Tue, Jul 08, 2008 at 10:27:35AM -0500, 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.
> 
> This is, basically, the method we use today for Astribank devices.
> Thereis a hirarchi under /proc/xpp that represents the different
> components (at the time we started it, sysfs was not stable enough).
> Each directory of span[1] has a file called zt_registration that allows
> registering and unregistering the span.
> 
> There's a utility called zt_registration (and now: dahdi_registration)
> that registers all the available spans in the required order. We use an
> order of "connectors", that happens to be persistant accross reboots and
> such.
> 
> So far so good. But where are the problems?
> 
> One problem is that we can never tell when "all of the devices have been
> plugged. We get udev events for a device that is plugged. Nobody
> notifies us that "all the devices were plugged". How long should we
> wait?

The dahdi_registration tool could be configured to know *all* the devices that 
it expects to show up, and wait a configurable number of seconds for them. 
Similarly to how the zaptel init script waits for the /dev/zap devices to show up.

> 
> And then suppose we plugged all the devices. The sysadmin can suddenly
> plug in a new one. Right now it will be the last to register. But
> chances are that on next reboot it will be "somewhere in the middle".
> And thus the configuration that works now will break after reboot.

In this case, since the dahdi_registration utility is loading devices based no 
unique name, and the new device would presumably have a unique name, it would 
be registered in that same order the next time the system is booted.
> 
> It also means that a driver has to be able to do something useful when
> not registered to Zaptel (before registering? Also support
> unregistering?)

The drivers can load their firmware, initialize the cards, export their sysfs 
attributes all before getting the command to register.  For cards with hardware 
echo cancellers that need to have the firmware loaded dynamically, this could 
speed up things, since the drivers are all loaded early (possibly parallely) 
getting their devices ready while other daemons are started up, then be ready 
to just register when commanded.