[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 11:54 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)?
====================================================================== 

---------------------------------------------------------------------- 
 tzafrir - 10-22-07 11:54  
---------------------------------------------------------------------- 
Usually I'm all for doing things in userspace. However in this case the
work to do is simply unnecessary.

If you think that this patch is bad due to "doing in userspace", please
provide a scenario where it actually gets in the way or handling things in
userspace.

For example, let's consider a strange user trying to force a specific
channel to be loopstart rather than kewlstart. With this patch in place the
user can still use the approach taken by the current init.d script: write a
zaptel.conf with just the channels the user wants to override and run ztcfg
at the zaptel init.d script.

bkruse mentioned zapscan that is run automatically at the init.d script of
asterisknow. In the case of our user, zapscan will always override his
channels in zaptel.conf and he will not be able to use loopstart
signalling.

Anyway, the proper fix is to run a partial ztcfg from udev for each span
separately once I get proper device model support. This is the proper place
to move things to userspace. Right now userspace simply has not enough
data. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-22-07 11:54  tzafrir        Note Added: 0072369                          
======================================================================