[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-24-2007 01:37 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-24-07 01:37  
---------------------------------------------------------------------- 
I have looked at your implementation and its nice (code is clear and file
less than 1000 lines...thanks -- zaptel needs a lot of redesign at least
zaptel-base 
should be split in 5 or 6 files, ok that's not of our business right
now).

Apparently you made a separate bus in sysfs to work with virtual devices,
well thats a clean approach however I think that using the class approach
of zaptel could be better fitted -- I am not an expert of linux device
model but I think classes have been created so as to abstract a behavior,
and its class devices to  abstract devices from a logical point. I think
that buses/devices are reserved for real hardware buses and devices. 
 Zaptel base already creates a class called "zaptel" in sysfs and you
could simply modify its class device nodes instead of duplicating some
information in a virtual bus.
I do agree that classes are tricky to handle when dealing with all kernel
versions from 2.6.1 to 2.6.16 but this would be the better approach IMHO.

Now, about the necessary information to be exported (personally I don't
need any yet), If what you need is auto configuration of channels a simple
a look at ZT_GET_PARAMS ioctl and ztcfg makes me think you should add:
 - channel's master number
 - channel's current law (take a look at ZT_GET_PARAMS ioctl current law
is detemined by pointer checking on xlaw)
 - channel's idlebits
(Yes some information may be related to digital signalling but it does not
hurt to expose that information).

And then you could probably make good heuristics from user-space to
properly get a channel configured.

Another Note: you do not lock on channel access nor in span access, it may
not hurt much because these are only read accesses but take in account that
sysfs information may be out of meaning then.












Personnaly I do not need anything cause I don't need this patch, however
for what you expect (autoconfiguring a channel), you may want 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-24-07 01:37  meneault       Note Added: 0072445                          
======================================================================