[asterisk-dev] A plan for span

[Tzafrir Cohen]

On Tue, Jul 08, 2008 at 10:27:35AM -0500, Shaun Ruffell wrote:

> 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 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?

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.

It also means that a driver has to be able to do something useful when
not registered to Zaptel (before registering? Also support
unregistering?)

[1] Technically: of something called XPD. But it is will be registered
    to Zaptel as a single span.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir