[svn-commits] sruffell: tools/trunk r4604 - /tools/trunk/README
SVN commits to the Digium repositories
svn-commits at lists.digium.com
Thu Jul 10 16:45:39 CDT 2008
Author: sruffell
Date: Thu Jul 10 16:45:39 2008
New Revision: 4604
URL: http://svn.digium.com/view/dahdi?view=rev&rev=4604
Log:
Updating the README, but still needs another editing pass to make sure that it
makes sense now that DAHDI splits the user parts from the kernel parts, unlike
Zaptel.
Modified:
tools/trunk/README
Modified: tools/trunk/README
URL: http://svn.digium.com/view/dahdi/tools/trunk/README?view=diff&rev=4604&r1=4603&r2=4604
==============================================================================
--- tools/trunk/README (original)
+++ tools/trunk/README Thu Jul 10 16:45:39 2008
@@ -1,9 +1,9 @@
-Zapata Telephony Interface Driver
+DAHDI Telephony Interface Driver
=================================
Asterisk Development Team <asteriskteam at digium.com>
$Revision$, $Date$
-DAHDI stands for Digium Advanced Hardware Digital Interface. This
+DAHDI stands for Digium Asterisk Hardware Device Interface. This
package contains the userspace tools to configure the kernel modules
included in the package dahdi-linux.
@@ -33,21 +33,21 @@
- wctdm24xxp:
* Digium TDM2400P/AEX2400: up to 24 analog ports
* Digium TDM800P/AEX800: up to 8 analog ports
- * Digium TDM410: up to 4 analog ports
+ * Digium TDM410P: up to 4 analog ports
- wctdm:
* Digium TDM400P: up to 4 analog ports
- xpp: Xorcom Astribank: a USB connected unit of up to 32 ports
- (includeing the digital BRI and E1/T1 modules)
+ (including the digital BRI and E1/T1 modules)
- wcfxo: X100P, similar and clones. A simple single-port FXO card
Other Drivers
~~~~~~~~~~~~~
- pciradio: Zapata Telephony PCI Quad Radio Interface
-- wctc4xxp: Digium hardware transcoder cards (also need zttranscode)
-- dahdi_dynamic_eth: TDM over Ethernet (TDMoE) driver. Requires ztdynamic
-- dahdi_dynamic_loc: Mirror a local span. Requires ztdynamic
-- dahdi_dummy: A dummy driver that only provides a zaptel timing source.
+- wctc4xxp: Digium hardware transcoder cards (also need dahdi_transcode)
+- dahdi_dynamic_eth: TDM over Ethernet (TDMoE) driver. Requires dahdi_dynamic
+- dahdi_dynamic_loc: Mirror a local span. Requires dahdi_dynamic
+- dahdi_dummy: A dummy driver that only provides a DAHDI timing source.
Build Requirements
@@ -76,11 +76,11 @@
Extra Libraries
~~~~~~~~~~~~~~~
Some libraries are needed for extra utilities that are provided with
-Zaptel
+DAHDI.
- libusb is needed for building fpga_load, needed for firmware loading of
the Xorcom Astribank.
-- libnewt is needed to build the optional but useful utility zttool.
+- libnewt is needed to build the optional but useful utility dahdi_tool.
Distribution-Specific Instructions
@@ -107,20 +107,17 @@
Partial Build/Install
^^^^^^^^^^^^^^^^^^^^^
There are some make targets that are provided to build or install just
-parts of Zaptel:
+parts of DAHDI:
. Build targets:
- - make programs: Build just the Zaptel userspace programs. partial
+ - make: Build DAHDI userspace programs. partial
targets of it:
- * make 'utilname': builds 'utilname' alone (e.g: `make ztdiag`)
+ * make 'utilname': builds 'utilname' alone (e.g: `make dahdi_diag`)
* make utils: Build libtonezone.
* make libs: Build libtonezone.
. Install targets:
- - make install-programs: Userspace: Partial targets of it are:
- * make install-utils: install Zaptel userspace programs and
- and basic support files.
- * make install-libs: install libtonezone
- * make install-include: install zaptel.h
+ - make install: Installs user space tools into /usr/sbin/ (TODO - list
+ partial targets)
- make config: should be run once to configure
Building to a Subtree
@@ -194,18 +191,18 @@
The kernel modules can be configured through module parameters. Module
parameters can optionally be set at load time. They are normally set (if
needed) by a line in a file under /etc/modprobe.d/ or in the file
-/etc/modprobe.conf (Or /etc/modules.conf in kernel 2.4).
+/etc/modprobe.conf.
Example line:
- options zaptel debug=1
+ options dahdi debug=1
The module parameters can normally be modified at runtime through sysfs:
- pungenday:~# cat /sys/module/zaptel/parameters/debug
+ pungenday:~# cat /sys/module/dahdi/parameters/debug
0
- pungenday:~# echo 1 >/sys/module/zaptel/parameters/debug
- pungenday:~# cat /sys/module/zaptel/parameters/debug
+ pungenday:~# echo 1 >/sys/module/dahdi/parameters/debug
+ pungenday:~# cat /sys/module/dahdi/parameters/debug
1
Viewing and setting parameters that way is possible as of kernel 2.6 .
@@ -245,7 +242,7 @@
* 4: LEDS - Anything related to the LEDs status control. The driver
produces a lot of messages when the option is enabled.
* 8: SYNC - Synchronization related messages.
- * 16: SIGNAL - Zaptel signalling related messages.
+ * 16: SIGNAL - DAHDI signalling related messages.
* 32: PROC - Messages related to the procfs interface.
* 64: REGS - Reading and writing to chip registers. Tends to flood
logs.
@@ -294,120 +291,117 @@
include::tonezones.txt[]
-Zaptel PERL modules
+DAHDI PERL modules
-------------------
The directory xpp/utils has, in addition to helper utilities for the
Xorcom Astribank, a collection of perl modules to provide information
-related to Zaptel. The perl modules themselves are under xpp/utils/zconf .
+related to DAHDI. The perl modules themselves are under xpp/utils/zconf .
In xpp/utils there are several utilities that use those modules:
-- xpp-specific: zt_registration, xpp_sync, xpp_blink .
-- General: lszaptel, zapconf, zaptel_hardware
-
-The zaptel perl modules will currently only be automatically installed
-if you happen to isntall the xpp module. This should be the defualt, but
-you can also initiate it manually by running:
+- xpp-specific:dahdi_registration, xpp_sync, xpp_blink .
+- General: lsdahdi, dahdi_genconf, dahdi_hardware
+
+The DAHDI perl modules will currently only be automatically installed if you
+happen to install the xpp module. This should be the default, but you can also
+initiate it manually by running:
make -C xpp/utils install
Those utilities require the perl modules to be installed, however they
will also look for them in the directory zconf, and thus can be run
-directly from the zaptel source tree. For example:
-
- ./xpp/utils/zaptel_hardware
+directly from the DAHDI source tree. For example:
+
+ ./xpp/utils/dahdi_hardware
To get usage information on a program, you can also use perldoc
(sometimes provided in a package separate from perl itself). For
instance:
- perldoc ./xpp/utils/lszaptel
+ perldoc ./xpp/utils/lsdahdi
Some of them are specific for the Xorcom Astribank and described in its
docuemntation. the others are:
-lszaptel::
- A somewhat glorified `cat /proc/zaptel/*`.
+lsdahdi::
+ A somewhat glorified `cat /proc/dahdi/*`.
zapconf::
An currently experimental and intended to eventually replace
genzaptelconf by a more maintainable code.
-zaptel_drivers::
+dahdi_drivers::
A two-liner script (not installed by default) that simply returns the
modules that should be modprobed on this system.
-zaptel_hardware::
+dahdi_hardware::
Uses the information from sysfs and its own knowledge to show
- what PCI/USB Zaptel hardware is connected and if it is currently used
- by a driver. Shows also some more information for Astrobanks from
+ what PCI/USB DAHDI hardware is connected and if it is currently used
+ by a driver. Shows also some more information for Astribanks from
/proc/xpp .
Internals
---------
-Zaptel Device Files
+DAHDI Device Files
~~~~~~~~~~~~~~~~~~~
-Userspace programs will usually interact with Zaptel through device
-files under the /dev/zap directory (pedantically: characted device files
+Userspace programs will usually interact with DAHDI through device
+files under the /dev/dahdi directory (pedantically: characted device files
with major number 196) . Those device files can be generated statically
or dynamically through the udev system.
-* /dev/zap/ctl (196:0) - a general device file for various information and
- control operations on the zaptel channels.
-* /dev/zap/NNN (196:NNN) - for NNN in the range 1-249. A device file for
- zaptel channel NNN. It can be used to read data from the channel
+* /dev/dahdi/ctl (196:0) - a general device file for various information and
+ control operations on the DAHDI channels.
+* /dev/dahdi/NNN (196:NNN) - for NNN in the range 1-249. A device file for
+ DAHDI channel NNN. It can be used to read data from the channel
and write data to the channel.
-* /dev/zap/transcode (196:250) - Used to connect to a zaptel transcoding
+* /dev/dahdi/transcode (196:250) - Used to connect to a DAHDI transcoding
device.
-* /dev/zap/timer (196:253) - Allows setting timers. Used anywhere?
-* /dev/zap/channel (196:254) - Can be used to open an arbitrary zaptel
- channel. This is an alternative to /dev/zap/NNN that is not limited to
+* /dev/dahdi/timer (196:253) - Allows setting timers. Used anywhere?
+* /dev/dahdi/channel (196:254) - Can be used to open an arbitrary DAHDI
+ channel. This is an alternative to /dev/dahdi/NNN that is not limited to
249 channels.
-* /dev/zap/pseudo (196:255) - A timing-only device. Every time you open
- it, a new Zaptel channel is created. That Zaptel channel is "pseudo" -
- Zaptel recieves no data in it, and only sends garbage data with the
- same timing as the Zaptel timing master device.
-
-
-Zaptel Timing
+* /dev/dahdi/pseudo (196:255) - A timing-only device. Every time you open
+ it, a new DAHDI channel is created. That DAHDI channel is "pseudo" -
+ DAHDI recieves no data in it, and only sends garbage data with the
+ same timing as the DAHDI timing master device.
+
+
+DAHDI Timing
~~~~~~~~~~~~~
-A PBX system should generally have a single clock. If you are connected
-to a telephony provider via a digital interface (e.g: E1, T1) you should
-also typically use the provider's clock (as you get through the
-interface). Hence one important job of Asterisk is to provide timing to
-the PBX.
-
-Zaptel "ticks" once per millisecond (1000 times per second). On each
-tick every active zaptel channel reads and 8 bytes of data. Asterisk
-also uses this for timing, through a zaptel pseudo channel it opens.
-
-However, not all PBX systems are connected to a telephony provider via
-a T1 or similar connection. With an analog connection you are not synced
-to the other party. And some systems don't have Zaptel hardware at all.
-Even a digital card may be used for other uses or is simply not
-connected to a provider. Zaptel cards are also capable of providing timing
-from a clock on card. Cheap x100P clone cards are sometimes used for
-that pupose.
-
-If all the above fail, you can use the module ztdummy to provide timing
-alone without needing any zaptel hardware. It will work with most
-systems and kernels.
-
-You can check the zaptel timing source with zttest, which is a small
-utility that is included with zaptel. It runs in cycles. In each such
-cycle it tries to read 8192 bytes, and sees how long it takes. If zaptel
-is not loaded or you don't have the device files, it will fail
-immedietly. If you lack a timing device it will hang forever in the
-first cycle. Eitherwise it will just give you in each cycle the percent
-of how close it was. Also try running it with the option -v for a
-verbose output.
-
-To check the clock source that is built into ztdummy, you can either
-look at title of its span in /proc/zaptel file for a "source:" in the
-description. Or even run:
-
- strings zaptel.ko | grep source:
+A PBX system should generally have a single clock. If you are connected to a
+telephony provider via a digital interface (e.g: E1, T1) you should also
+typically use the provider's clock (as you get through the interface). Hence
+one important job of Asterisk is to provide timing to the PBX.
+
+DAHDI "ticks" once per millisecond (1000 times per second). On each tick every
+active DAHDI channel reads and 8 bytes of data. Asterisk also uses this for
+timing, through a DAHDI pseudo channel it opens.
+
+However, not all PBX systems are connected to a telephony provider via a T1 or
+similar connection. With an analog connection you are not synced to the other
+party. And some systems don't have DAHDI hardware at all. Even a digital card
+may be used for other uses or is simply not connected to a provider. DAHDI
+cards are also capable of providing timing from a clock on card. Cheap x100P
+clone cards are sometimes used for that pupose.
+
+If all the above fail, you can use the module dahdi_dummy to provide timing
+alone without needing any DAHDI hardware. It will work with most systems and
+kernels.
+
+You can check the DAHDI timing source with dahdi_test, which is a small
+utility that is included with DAHDI. It runs in cycles. In each such cycle it
+tries to read 8192 bytes, and sees how long it takes. If DAHDI is not loaded
+or you don't have the device files, it will fail immediately. If you lack a
+timing device it will hang forever in the first cycle. Otherwise it will just
+give you in each cycle the percent of how close it was. Also try running it
+with the option -v for a verbose output.
+
+To check the clock source that is built into dahdi_dummy, you can either look
+at title of its span in /proc/dahdi file for a "source:" in the description.
+Or even run:
+
+ strings dahdi.ko | grep source:
Spans and Channels
~~~~~~~~~~~~~~~~~~
-Zaptel provides telephony *channels* to the userspace applications.
-Those channels are channels are incoreperated into logical units called
+DAHDI provides telephony *channels* to the userspace applications.
+Those channels are channels are incorperated into logical units called
*spans*.
With digital telephony adapters (e.g: E1 or T1), a span normally
@@ -419,13 +413,12 @@
generated, and ditto for spans.
-PROCFS Interface: /proc/zaptel
+PROCFS Interface: /proc/dahdi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A simple way to get the current list of spans and channels each span
-contains is the files under /proc/zaptel . /proc/zaptel is generated by
-zaptel as it loads. As each span registers to Zaptel, a file under
-/proc/zaptel is created for it. The name of that file is the number of
-that span.
+A simple way to get the current list of spans and channels each span contains
+is the files under /proc/dahdi . /proc/dahdi is generated by DAHDI as it
+loads. As each span registers to DAHDI, a file under /proc/dahdi is created
+for it. The name of that file is the number of that span.
Each file has a 1-line title for the span followed by an empty line and
then a line for each channel of the span.
@@ -440,12 +433,12 @@
Span 1: XBUS-00/XPD-00 "Xorcom XPD #0/0: FXS"
The channel line for each channel shows its channel number, name and the
-actual signalling assigned to it through ztcfg. Before being configured
-by ztcfg: This is Zaptel channel 2, whose name is 'XPP_FXS/0/0/1'.
+actual signalling assigned to it through dahdi_cfg. Before being configured by
+dahdi_cfg: This is DAHDI channel 2, whose name is 'XPP_FXS/0/0/1'.
2 XPP_FXS/0/0/1
-After being configured by ztcfg: the signalling 'FXOLS' was added. FXS
+After being configured by dahdi_cfg: the signalling 'FXOLS' was added. FXS
channels have FXO signalling and vice versa:
2 XPP_FXS/0/0/1 FXOLS
@@ -458,18 +451,17 @@
ABI Compatibility
~~~~~~~~~~~~~~~~~
-Like any other kernel code, Zaptel strives to maintain a stable
-interface to userspace programs. The API of Zaptel to userspace
-programs, zaptel.h, has remained backword-compatible for a long time and
-is expected to remain so in the future. With the ABI (the bits
-themselves) things are slightly trickier.
-
-Zaptel's interface to userspace is mostly ioctl(3) calls. Ioctl calls
+Like any other kernel code, DAHDI strives to maintain a stable interface to
+userspace programs. The API of DAHDI to userspace programs, dahdi/user.h, has
+remained backword-compatible for a long time and is expected to remain so in
+the future. With the ABI (the bits themselves) things are slightly trickier.
+
+DAHDI's interface to userspace is mostly ioctl(3) calls. Ioctl calls
are identified by a number that stems from various things, one of which
is the size of the data structure passed between the kernel and
userspace.
-Many of the Zaptel ioctl-s use some sepcific structs to pass information
+Many of the DAHDI ioctl-s use some sepcific structs to pass information
between kernel and userspace. In some cases the need arose to pass a few
more data members in each call. Simply adding a new member to the struct
would have meant a new number for the ioctl, as its number depends on
@@ -508,45 +500,25 @@
0xC0044A3E . ZT_EXAMPLE_V1 would have the same value. But the new value
of ZT_EXAMPLE would be 0xC0084A3E .
-Programs built with the original zaptel.h (before the change) use the
-original ioctl, whether or not the kerenl code is actually of the newer
+Programs built with the original dahdi/user.h (before the change) use the
+original ioctl, whether or not the kernel code is actually of the newer
version. Thus in most cases there are no compatibility issues.
-When can we have compatibility issues? if we have code built with the
-new zaptel.h, but the loaded kernel code (modules) are of the older
-version. Thus the userspace program will try to use the newer ZT_EXAMPLE
-(0xC0084A3E). But the kernel code has no handler for that ioctl. The
-result: the error 25, ENOTTY, which means "Inappropriate ioctl for
-device".
-
-As a by-product of that method, for each interface change a new #define
-is added. That definition is for the old version and thus it might
-appear slightly confusing in the code, but it is useful for writing code
-that works with both versions of Zaptel.
-
-
-Past Incompatibilities
-^^^^^^^^^^^^^^^^^^^^^^
-
-.Zaptel 1.4.10:
-* Semantics of ZT_LOADZONE. Using newer ztcfg with older modules will
- yield -EINVAL with the kernel message 'Invalid tone (96) defined'
-
-.Zaptel 1.4.8:
-* ZT_GET_PARAMS_V1
-* ZT_SET_PARAMS_V1
-* ZT_SPANINFO_V2
-
-.Zaptel 1.4.6:
-* ZT_SPANINFO_V1
-
-ZT_SPANINFO_V1 was originally called (up to zaptel 1.4.8)
-"ZT_SPANINFO_COMPAT".
+When can we have compatibility issues? If we have code built with the new
+dahdi/user.h, but the loaded kernel code (modules) are of the older version.
+Thus the userspace program will try to use the newer ZT_EXAMPLE (0xC0084A3E).
+But the kernel code has no handler for that ioctl. The result: the error 25,
+ENOTTY, which means "Inappropriate ioctl for device".
+
+As a by-product of that method, for each interface change a new #define is
+added. That definition is for the old version and thus it might appear
+slightly confusing in the code, but it is useful for writing code that works
+with all versions of DAHDI.
PPP Support
-----------
-Zaptel digital cards can provide data channels through ppp as
+DAHDI digital cards can provide data channels through ppp as
point-to-point connections. This requires a plugin to the ppp daemon
that is included in the ppp/ subdirectory. To install it:
@@ -564,21 +536,21 @@
CONFIG_HDLC .
-What is the license for the zaptel driver?
+What is the license for the DAHDI drivers?
------------------------------------------
libpri is distributed under the terms of the GNU General Public License,
which permit its use and linking with other GPL'd software only.
The GNU GPL is included in the file LICENSE in this directory.
-If you wish to use the zaptel drivers in an application for which the
-GPL is not appropriate (e.g. a proprietary embedded system), licenses
-under more flexible terms can be readily obtained through Digium, Inc.at reasonable cost.
+If you wish to use the DAHDI drivers in an application for which the GPL is
+not appropriate (e.g. a proprietary embedded system), licenses under more
+flexible terms can be readily obtained through Digium, Inc.at reasonable cost.
How do I report bugs or contribute?
-----------------------------------
Please report bug and patches to the Asterisk.org bug tracker at
-http://bugs.digium.com in the "zaptel" category.
+http://bugs.digium.com in the "DAHDI" category.
Does anything use this library so far?
More information about the svn-commits
mailing list