[Asterisk-Dev] The Zaptel init scripts must die!

[Kevin P. Fleming]

Tzafrir Cohen wrote:

> 2. You canactually remove that listing, and rely on either discover or
> hotplug to pick it up. Both are expected to. 

With current udev (unstable 'sid'), hotplug is a deprecated package. I 
haven't tested whether discover will make the modules autoload or not, 
but I think it's not doing that on my system.

> 2. The current zaptel drivers do not allow dynamic unregistration and
>    registration. But let's ignore that for now. The main problem here is
>    not just fixing them to do so, but also the fact that the only
>    identifiers you have are the span numbers and channel numbers, which
>    are too dynamic and wildly depend on the load order. 

Correct.

>    Something that is a bit more permanent is the physical address in the
>    system. E.g: the PCI slot number. There should be some sort of "PCI
>    address" for every PCI card, I believe (the first column in lspci).

Exactly my idea :-)

>    In USB there is something rather similar. Not sure about pcmcia and
>    ISA.

They don't matter, we can let the producers of PCMCIA/CardBus and ISA 
Zaptel gear deal with that in their drivers.

>    There is also nothing equivalent of a MAC address.

With current hardware that is true, but some of the new stuff (TDM2400P) 
may change that.

> 3. We had it working rather dynamic, but then noticed that we nust
>    configure zapata.conf at the same time because it replicates much of
>    the information in zaptel.conf and changing it requires asterisk
>    restart.

Agreed.

I'm thinking along these lines:

Modify zaptel core and drivers so that when a driver binds to a 
card/device, it does only two things: register that card/device with the 
core and provide a system-unique identifier for that card/device. For 
existing PCI devices, this would be the PCI location info; for USB it 
would be the same. Both of these would be superseded by MAC (or 
equivalent) for devices that can supply a globally-unique identifier.

Registration of that card with the core would include telling the core 
how many spans the card supports, but would _not_ assign span or channel 
numbers to any of the card's interfaces.

This registration would register 'something' (some sort of device, 
probably) in sysfs, which would cause kernel uevents to be handled by 
udev. There would be a rule in the udev configuration for when these 
devices appear, to run ztcfg to configure that device _only_ (by passing 
the identifier gleaned from sysfs to ztcfg). ztcfg would configure the 
device, which would assign (by reading info from zaptel.conf, not 
dynamically assign) span numbers and channel numbers to the device's 
interfaces. zapata.conf would continue to reference span numbers and 
channel numbers, but they would be deterministic.

Configuration of those span numbers and channel numbers would then 
generate more kernel uevents, which would create the actual Zap device 
nodes for Asterisk or other applications to use.

Along with some changes to chan_zap to allow it to gracefully start when 
configured channels are not present, this would go a long way towards 
providing configuration flexibility and less 'surprise' when things are 
changed around.

Comments?