[asterisk-bugs] [Zaptel 0007613]: [patch][post 1.4] automatic configuration for analog channels

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=7613 
====================================================================== 
Reported By:                tzafrir
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   7613
Category:                   zaptel (the module)
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
Zaptel Version:              SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 1253 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             07-28-2006 20:45 CDT
Last Modified:              10-22-2007 07:48 CDT
====================================================================== 
Summary:                    [patch][post 1.4] automatic configuration for analog
channels
Description: 
All zaptel channels and spans have to be configured from userspace after
they were registered before they could be used. However for analog spans,
there are simple and sane defults that would probably Just Work in most of
the cases.

In the attached patch:
1. the action of the ioctl ZT_CHANCONFIG was moved to a separate function
(zt_chanconfig) . 

2. if the module parameter do_ztcfg is set to a value other than 1, it
will configure "simple" channels: channels that support either fxsks or
fxoks signalling , but not both. This should work for wcfxo, wcusb, xpp
(both fxs and fxo) and probably wctdm/wctdm24xxp as well, if sigcap is
properly set for each channel.

Open issues:

A. The patch is not yet tested

B. Would anybody comment on the strange error handling in the ioctl? What
exactly should and shouldn't be don't in case of failure? 

I basically moved the code as-is with minimal rewriting. The only
significant change is that in case of failure the copy to userspace is not
done before the hangup.

C. Any ideas regarding the validity of the hueristic I use in (2)?
====================================================================== 

---------------------------------------------------------------------- 
 meneault - 10-22-07 07:48  
---------------------------------------------------------------------- 
IHMO I would say that what could be done in user-space should be done in
user-space. I think that most of zaptel drivers are already overloaded from
things that should have been done in userspace. It results in a less
readable, less maintainable code.

As you pointed out yourself, ztcfg does more than actually setting the
channel signalling type, and in the future it could even do more.
In the future, analog drivers may support other signalling types, for
instance Ground Start -- How would you choose beetween them? Only a user
can do that.

And AFAIK every 'asterisk for dumbs' distribution already comes with
scripts that handle this heuristic pretty well.

However leveraging the ioctl function is not a bad idea so moving 
ZT_CHANCONFIG into a separate chunk of code for modularity (could be good
-- but in this case you could make it inline). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-22-07 07:48  meneault       Note Added: 0072331                          
======================================================================