[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-23-2007 02:09 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-23-07 02:09  
---------------------------------------------------------------------- 
Tzafrir:
About 'zapscan', from what I understand this is just a limitation of the
boot process of a specific distribution that don't give the user the
possibility to override the 'Asterisk For Now' heuristics. That's not a
matter of zaptel from my point of view and as bkruse said the work to allow
this is underway.

As I previously mentioned configuring a channel is not only a matter of
configuring its channel type, and the current implementation that need
configuring before use is the safer approach because it tells the user
'warning you didn't configure anything'. Guessing a proper signalling from
the sigcap of a channel is not deterministic it is a matter of choosing. In
kernel when choosing is required then it is up to the user-space to do so.

And I do agree that the udev way would be simply the cleanest way, a clean
approach would be:
- before registering a span the driver should determine its channel type.
(this may need a fix for instance for wctdm which determine it
afterwards)

- add environment variables to the hotplug event (from zaptel-base when
creating device for udev in zt_register).
One maybe VALID_CHANNELS (binary array of valid channels)
Other CHANNELS_CAP (binary array of capabilities for each channel)

- then any distribution may do its own script to respond to hotplug
events
 via udev and match its CHANNELS_CAP to give a common start to any zap
device building-up an automatic zaptel-auto.conf from that information,
then the zaptel-auto.conf would have to be merged from the user's
zaptel.conf.
At the end of the boot a simple call to ztcfg with zaptel-merged.conf and
that's over.

Note:
One different approach would be to generate an hotplug event for each
channel found rather than for each span (but that would need more code). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-23-07 02:09  meneault       Note Added: 0072394                          
======================================================================