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

[Tzafrir Cohen]

On Tue, Dec 13, 2005 at 03:03:51PM -0600, Kevin P. Fleming wrote:
> Tilghman Lesher wrote:
> 
> >Sure, but first, I want you to tell me how zaptel magically knows when
> >all relevant modules are loaded on a machine BEFORE running 'ztcfg',
> >so we don't get misfires on each successive module.  This is what the
> >Mandrake init scripts are designed to do:  load all the relevant
> >modules, preventing running ztcfg until the very end, when all the
> >channels are in place).  If you've magically fixed zaptel to run ztcfg
> >itself, but only after _every_ card module is loaded, then there's no
> >longer any need for init scripts.
> 
> Well, I know that on my Debian system with multiple card types installed 
> (TDM400P and TE405P), the modules are loaded and ztcfg runs successfully 
> without causing any errors, all by just listing the modules in /etc/modules.

1. However modprobe will give an annoying error message after the first
module was loaded, because you try torun ztcfg on a not yet
fully-configured system. modprobe will return an error status.

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

> 
> I suppose what we really need is to find some way to make this work 
> properly in the new udev/dynamic device/hotplug world and not require 
> static setups at all. That's a much larger change, but one that would be 
> welcome in my eyes.

1. hotplug allows some nifty tricks. Think of ztcfg -c custom_file for
   some of the needs. I have not found any real use for that, though.

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. 

   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).

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

   There is also nothing equivalent of a MAC address.

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.

4. We have a script of our own that regenerates zaptel.conf and zapata.conf . 
   This basically works for analog cards where there are sane defaults for 
   most things. For PRI things get messier.
   
   http://svn.debian.org/wsvn/pkg-voip/zaptel/trunk/debian/genzaptelconf

5. The whole configuration process, including the pair of zaptel.conf
   and ztcfg needs to be rethought. As an indication to that fact that
   it is not extendible: Digium chose not to extend it for fxotune, and
   rather generate another configu file under /etc . (what about
   /etc/zaptel, BTW?)

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