oslec with zaptel and dahdi: dependency for external modules
Basic question: how do I handle building external kernel modulesfrom
different packages that depend on one another?
(As for the workaround of getting either into mainline: tried, and
doesn't work. At least not now)
I have a module called "Mainmod" in package "mainmod-source", and it
depends on code from module "Provider" from package "provider-source".
If Provider is not available when Mainmod is built, there will be no
proper dependency between them. e.g: 'modprobe mainmod' will not pull
Provider and if Provider happens not to be loaded at the time, the load
of mainmod will fail.
This post regards post-Lenny issues.
So what do we have here:
Long ago (at around 2000) Jim Dixon developed a new T1/E1 card. He has
considered his card revolutionary[0] and thus named the card Tormenta
and the drivers (for FreeBSD at the time) were named Zapata Telephony,
after Emiliano Zapata.
At around that time a certain company (called "Zaptel Corporation)
thought "zaptel" is a nice name for calling cards. The site of that
company is http://zaptel.com/ .
Soon those drivers were ported to Linux as well. Mainly due to the help
of Mark Spencer who had a voip/telephony software called Asterisk for
which he wanted a decent hardware interface.
Since then Mark Specer has changed the name of his company to Digium,
and they are now the primary developers of both Zaptel and Asterisk.
The policy of the company is to dual-license code and hence contribution
to the project has sometimes met with difficulties. So not only is
Zaptel an external kernel module, but there are also some card drivers
that use it that are not included in the main distribution.
Thus the Debian package includes drivers from the "bristuff"
distribution, vzaphfc, a Zaptel driver for a Voicetronix card, and
others. There is a RFP for the Sangoma drivers
(http://bugs.debian.org/486160 ), and noone has yet asked for the Rhino
drivers, which are also actively maintained. Thus we so far
Thus we avoided the dependency problem by putting everything in the same
packaging. This has also made the Debian package a partial upstream.
Zaptel has also included a line echo canceller for quite some time. But
it wasn't well-designed and tested and never really worked properly.
Some cards have a hardware-based echo cancellers on-board. There are two
proprietary software-based echo cancellers (one from Octasic, and the
other is HPEC, that is distributed by Digium.
David Rowe has set out to create a better echo canceller. The result is
OSLEC: Open Source Line Echo Canceller:
http://www.rowetel.com/ucasterisk/oslec.html .
It is mostly used by zaptel, but also by mISDN . For both it requires
some patching. Upstream includes it as a separate source tarball (but
rarely releases tarballs. It is best to use latest SVN, normally).
Oslec actually works, which is why I wanted it in Debian. To avoid any
issues, I have chosen to include it as part of the package Zaptel. This
also required some repackaging but avoided the dependency mess. We also
don't really include mISDN (mISDN 1.1.x seems to be considered too
buggy, and mISDN 1.2 will hopefully make it to mainline kernel). So
Zaptel was the only user for us.
At around 2005 the Zaptel Corporation got annoyed by people looking for
"Zaptel[.com] [calling] card" and end up finding "Zap[ate ]tel[phony]
[PCI] cards". Sadly, they were the ones who registered the trademark and
thus once again a software of Mark Spencer had to be renamed. The new name
chosen was "DAHDI" (Digium Asterisk Hardware Device Interface[1]). While
not all people like the name and what it stands for, the rename took
place.
With the rename, some substantial changes were made and the kernel ABI
was explicitly broken (a different ioctl type, different /proc and /dev
directories).
Lenny has Zaptel 1.4.21 . Asterisk versions in the 1.4 branch as of the
upcoming 1.4.22 will build with either Zaptel or Dahdi. The upcoming
1.6.0 will only use DAHDI. Which means that we'll eventually need to
include DAHDI, though this is a post-Lenny task.
I have started packaging it
(at svn://svn.debian.org/pkg-voip/dahdi-linux/trunk ). If I want to use
the same method for including oslec, I'll have two versions of OSLEC in
the archive, which is probably not such a grand idea. Thus I need to put
OSLEC in a separate package.
So in short: we now have just one "zaptel" modules package. But it seems
that we need to have:
oslec
zaptel: uses oslec
dahdi: uses oslec
wanpipe: uses either zaptel or dahdi
And maybe some other drivers in the same position as wanpipe.
How will this get built?
Should a built provider-modules-$KVERS package include a snippet of
Module.symvers that will be used when building mainmod-modules-$KVERS ?
[0] The article was originally on asteriskdocs.org and on
zapatatelephony.org . Right now I can only find it in the archives:
http://web.archive.org/web/20050121120343/http://www.asteriskdocs.org/modules/tinycontent/index.php?id=10
http://zapatatelephony.org/ itself is a bit of archeology.
And in case you wonder: yes, those Zaptel cards do sell well even in
Mexico
[1] DAHDI is also the name of a board game from India and maybe of a
town/city in Iran.
--
Tzafrir Cohen | tzafrir@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tzafrir@cohens.org.il | | best
ICQ# 16849754 | | friend
Reply to: