[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-27-2007 05:52 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-27-07 05:52  
---------------------------------------------------------------------- 
In my previous message I told you how to better you sample, I have written
something from scratch that keep backward compatibility with existing
version  of zaptel and add support for any 2.6.* kernel (up to now of
course)
(code tested on a 2.6.9 kernel and on a 2.6.19 kernel).

note: It could even work on a 2.5.69 kernel I think but I have not checked
for,
please take note that current implementation enables CONFIG_ZAP_UDEV when
we use a 2.6.1 or latter kernel but I think it may not work on a 2.6.1
(because class_simple was added on 2.6.2 AFAIK).

My code moves the sysfs code of zaptel in a separate file zaptel-sysfs.c 
and it adds:
- uevent environment variables support (even if not so useful)
- a real good start to add the all the sysfs information we need
  in a clean an easy manner.
- take a look at zaptel-sysfs.c I have been really verbose in comments
  I talk about the sysfs /sys/zaptel tree.

- I have already added a lot of usefull information:
  each channel has got a sysfs directory containing: 
  - attributes name/channo/chanpos/sig/sigcap/master->channo/xlaw
  - symlink to its span
  each span has got a sysfs directory containing:
  - attributes name/desc/spanno/channels/alarms
  - a symlink for each of its channels

- Oh yes I forgot to mention I added proper locking when dealing with
attributes printing.

I deliver the code:
 - zaptel-sysfs.c (sysfs main code)
 - zaptel-sysfs-private.h (sysfs handy macros and defines to handle any
2.6 version of the kernel)
 - zaptel-base-c_patch_1_4_rev3211 (patch for zaptel-base.c)
 - zaptel-h_patch_1_4_rev3211      (patch for zaptel.h)
 - Makefile-kernel26_patch_1_4_rev3211  (patch for the Makefile)

I developed the code under branch 1.4 of zaptel revision 3211, however the
changes in zaptel code is minimal so the patch should apply on most zaptel
1.4 revisions. For the 1.2 branch I don't know.

I added license on the new files but feel free to modify them at your
needs.
If you have any questions ask me, you can modify them at will because I
don't plan to work on it these days since they work.

To print a new member of a span or a channel is a matter of two lines of
codes so It won't be too difficult to add something in.

Moreover As I said I have been really verbose (maybe too much) so you
won't get lost. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-27-07 05:52  meneault       Note Added: 0072587                          
======================================================================