[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-29-2007 06:46 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-29-07 06:46  
---------------------------------------------------------------------- 
You're completely right about class_device(s), they are now deprecated but
they are still valid to use (even in 2.6.24 kernel which was released 4
days ago AFAIK). 
I already said that it was tricky to handle it for the 2.6.* kernels and
it is,
linux device model is a new feature of 2.6 so it is not surprising.

Now, struct device should be used instead of class_device. However the
changes required are not so hard to get I think.
Apparently the idea was first announced in the 2.6.16 kernel, but the main
migration occurred in the 2.6.19 to 2.6.21 kernels.
However I am not sure we should make a rule that would migrate the
class_device to device since 2.6.19 kernels but rather wait until 2.6.24
because some patches have been added to the driver core later on to fix
some issues about this migration (2.6.22 and 2.6.23 may be safe but I have
not checked for).

I will give another shot to handle all this migration:
- I will fix identifiers issues (e.g. CLASS_DEVICE by DEVICE)
- I will replace class_device by device from 2.6.24 kernels
- Fix another issue about uevent API change from 2.6.23-rc8.

Then It will be up to you and the managers to decide what should be best.

My opinion is:
As every span is linked to only one device (AFAIK), each span is already
on a "real" bus so there is no need to add a new virtual bus.

IMHO using class and class_device under 2.6.2* kernel is good as:
1- we don't break the linux device model 
2- we don't break zaptel implementations and user spaces programs using
it
   (including startup scripts and every udev version)
3- we don't overload the sysfs tree duplicating information on it.
(The virtual bus way will break point 3 at least (and 1 IHMO only)).
I think that respecting 1 and 3 is really important if someday we wanted
the zaptel driver to be integrated in the kernel.

Then using class and device over 2.6.2* kernels is good as:
1- we can keep the same layout as with class_device (everything would be
still fetched under the "zaptel" class with the same identifiers if we want
to)
2- this will reflect the real hardware/driver relationships.
(Point 1 & 2 cannot be achieved without duplicating information using the
virtual bus method).

Note:
- this would be good to have zaptel be integrated into the mainline
kernel, this would avoid us all this handling about kernel versions!

Warning:
- my patches are not for 3211 revision of 1.4 branch but for the 3121
(sorry about that). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-29-07 06:46  meneault       Note Added: 0072611                          
======================================================================