[asterisk-dev] Zaptel project being renamed to DAHDI

[Tzafrir Cohen]

On Wed, May 21, 2008 at 09:02:37AM +0000, Tony Mountifield wrote:
> In article <935ead450805202155j46d90ba7s9b21c1bb86ec5dc4 at mail.gmail.com>,
> Jeffrey Ollie <jeff at ocjtech.us> wrote:
> > On Tue, May 20, 2008 at 5:59 PM, Tilghman Lesher
> > <tilghman at mail.jeffandtilghman.com> wrote:
> > 
> > > was a practical one: given the length of kernel release cycles
> > 
> > Uh, what?  The Linux kernel releases a new version every 3-4 months.
> > Between 2.6.24 and 2.6.25 there were over 750K lines of code changes:
> > 
> > $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > $ cd linux-2.6
> > $ git diff --shortstat v2.6.24..v2.6.25
> >  9738 files changed, 777371 insertions(+), 404514 deletions(-)
> > 
> > I fail to see how that could be described as "lengthy".
> 
> That is not the relevant factor. Most Asterisk systems are not built on
> the latest bleeding-edge kernel, they are built on a stable distribution
> with a long release cycle (e.g. RHEL, CentOS, rpath, etc). This is where
> the inertia is, which I agree makes it more sensible to build Zaptel/Daddy
> separately.

We only managed to fully adjust Zaptel to build with kernel 2.4.24 by
the time kernel 2.5.25 was released (that's a lag of ~3 monthes). In the
mean while Ubuntu Hardy managed to be released with a bad version.

RHEL still supports kernel 2.4 on RHEL2.1 (nearing its EOL) and on RHEL3
(still has more than two year to go). Support for 2.4 kernel has been
spotty in Zaptel for quite some time.

RHEL 4 up until 4.4 has failed to build Zaptel due to a bug in its
kernel headers. Is it our job to fix that? At the moment the source tree
of Zaptel includes a workaround for that (though it was only added well
after RHEL4.4 / Centos4.4 was released, because a certain distribution
kept using the Centos 4.3 kernel).

There is a similar problem with a Fedora Core 5 kernel which is unfixed.
There was a similar problem with all of RHEL5/Centos5 kernels that was
finally "resolved" by removing a certain debugging feature from the xpp
driver.

The install-modules target of Zaptel gets more and more aggressive in
nuking competing modules. Because it is not installed through the
distribution's package management system.

Is it our job to backport the driver to every old system out there?


If the issue at hand is providing code that is newer that the one in the
distributions, then the problem is not unique to Zaptel. There are
plenty of other vendors who need to provide their customers with newer
kernel code than the one installed on the system.

Recall that the issue is not the release cycle of kernel.org: (almost) 
nobody uses vanilla kernel.org directly, and those that do are precisly
those who know how to apply patches (or not afraid to follow
step-by-step instructions to do so).

The issue is how to push changes into prepackaged distributions. And
there are technical tools to do that. 


On dpkg-based systems it is possible to use dpkg-divert(1) to move aside
the prepackaged modules. This is used by at least one modules package
that is in the porcess of merging its code to the kernel (kvm).


I'm sure that there are similar technical solutions to this problem on
other systems.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir