[asterisk-dev] Zaptel project being renamed to DAHDI

[Vasil Kolev]

В 16:07 +0300 на 21.05.2008 (ср), Tzafrir Cohen написа:
>  
> > 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.
> 

... and the solution to this (the best from the technical standpoint) is
to just have dahdi in the mainline kernel. Then all the API changes will
get applied to it automatically and the development team will mostly
have to just submit the new features. 

That way also the distributions will have an easier way to pick this up
in a working state and not having to handle one more out-of-tree
project.

Of course, if this gets included in the mainline, all fixes to it (API
changes, etc) will be under GPL, so it will be impossible for Digium to
copy them back - which, if they want to keep the ability to relicense
it, will mean effectively to fork it themselves.

... although there are a few projects that manage to make drivers from
one code base for more than one kernel, so maybe parts of what they're
doing can be adopted?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: =?UTF-8?Q?=D0=A2=D0=BE=D0=B2=D0=B0?=
	=?UTF-8?Q?_=D0=B5?= =?UTF-8?Q?_=D1=86=D0=B8=D1=84=D1=80=D0=BE=D0=B2=D0=BE?=
	=?UTF-8?Q?_=D0=BF=D0=BE=D0=B4=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=B0?=
	=?UTF-8?Q?_=D1=87=D0=B0=D1=81=D1=82?= =?UTF-8?Q?_=D0=BE=D1=82?=
	=?UTF-8?Q?_=D0=BF=D0=B8=D1=81=D0=BC=D0=BE=D1=82=D0=BE?=
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080522/28c4d359/attachment.pgp