[asterisk-dev] automatic "ztcfg" for analog cards

[Tzafrir Cohen]

On Sun, Jul 30, 2006 at 09:53:01AM -0500, Steven wrote:
> On Sun, 2006-07-30 at 10:54 +0300, Tzafrir Cohen wrote:
> > Hi
> > 
> > I said before that ztcfg should not be necessary for analog cards...
> > So here is http://bugs.digium.com/view.php?id=7613 to implement it.
> > 
> > This patch generlly does two things:
> > 
> > 1. Moves almost all the functionality of the ioctl ZT_CHANCONFIG to a
> > separate function.
> > 
> > 2. Calls that function from the end of zt_register for each channel if
> > exactly one of the following two conditions hold:
> > 
> > * The channel is capable of fxoks signalling
> > * The channel is capable of fxsks signalling
> > 
> > In such a case the channel is probably an analog channel. This seems to
> > also hold for TDM400P/2400P cards: slots with no modules have both
> > capabilities whereas slots with a certain module have just one specific
> > capability.
> 
> Those signalling choices are also available for T1 spans.

Yes. Both of them. Hence it should not be affecte. I did ask for
examples where this breaks. 

Maybe it should be further tweaked. Maybe there should be some sort of 
blacklist or whitelist of availble capabilities or driver names, or the 
driver should provide an extra field in struct zt_span.

This is why I asked for inputs from others.

> 
> > I consider KS a very sane default. If one needs LS or GS, ztcfg can
> > always be used. But for most people this would just work. You'd just
> > have to set the coutry on zaptel.conf, and that can never fail.
> 
> So this shortcut is for those on the lower end of the zaptel deployment
> scale 

And making their life much easier with no price for you (have you
noticed the extra module variable (run-time settable) that configures
this behaviour meaningless to you?

> and yet does nothing for the rest except put more lines of code
> into the drivers that potentially could have a bug now or later.

IMHO the current behaviour of automatic run of ztcfg on modprobe is
buggier, as it generates false "modprobe errors".

This now, along with a few other small patches I wrote, makes Zaptel
hardware truely hotpluggable. There may be other ways of implementing
it, but they seem more complicated.

Any decent method for auto-configuring zaptel channels/spans on
connection requires some exposure of spans information. Note the zero
replies I got to my previous post. As it seems now, that will be a major
change and will happen some time in the distant future.

This is a simple patch that Just Works and is small enough to add to our
distro even if upstream does not like it.

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