[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-30-2007 09:04 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-30-07 09:04  
---------------------------------------------------------------------- 
Ok for asterisk-dev mailing list.
Anyway I should post my second shot that handle issues related to
class_device/device migration.

So here you have:
- zaptel-h_patch_1_4_rev3121
- zaptel-base-c_patch_1_4_rev3121
- Makefile-kernel26_patch_1_4_rev3121
- zaptel-sysfs.c
- zaptel-sysfs-private.h
- zaptel-sysfs.h

Please note that:
- I arbitrarily set the class_device to device migration since linux
2.6.24.
- It was tested on 2.6.9 kernel (with wcfxo and wctdm for the
spans/channels)
  and on a 2.6.19 kernel (with ztdummy for the span)
- Even if it wasn't tested on a 2.6.24 I forced the migration to device
on
my 2.6.19 kernel and it worked well (as well as it should on a 2.6.19).
- Only thing not tested the API uevent change that happened on 2.6.24. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-30-07 09:04  meneault       Note Added: 0072723                          
======================================================================