[asterisk-dev] Re: Kernel modules => mainline kernel

[Steven Critchfield]

On Mon, 2007-02-12 at 19:27 +0100, Benny Amorsen wrote:
> >>>>> "MF" == Matthew Fredrickson <creslin at digium.com> writes:
> 
> MF> I think part of it is that we want to keep any changes we make
> MF> fairly accessible. What happens if we start rewriting some of the
> MF> APIs in zaptel and distributions start compiling it into the
> MF> kernel? That means that every user that wants to upgrade needs to
> MF> recompile their kernel.
> 
> Zaptel needs a stable API in order to go into the mainline kernel. It
> is about time it got one anyway.

Hopw often do you upgrade asterisk? How often do you upgrade zaptel?
Most production uses of asterisk/zaptel are the "if it isn't broke,
don't fix it" type. I just retired a machine that has been in service
without a code upgrade since I think the pre 1.0 releases. It was
retired for hardware failure not software failure. So from our
perspective, the API was solid and never changed.

> An unstable API keeps you locked into Asterisk. A bugfix to Zaptel
> could be released which includes changes to the API, and users of
> competing software PBX'es would have to wait for those PBX'es to
> update to the new API. I presume that is why basically none of the
> Asterisk-competitors support Zaptel cards.

If that was the reason behind not supporting zaptel, then they would
have to come up with a reason why they couldn't fork that code base.
Also, why should Digium and the support structure around asterisk care
what asterisk competitors reasons are for not using the hardware? Unless
we choose to use that software or support it, it is irrelavent to this
mailing list.
 
> MF> This also makes users of zaptel more aware of changes, bug fixes
> MF> and updates that we make, that may not be deemed "worthy" by
> MF> distribution X to be reason to update the -kernel.[rpm,deb]. I
> MF> think that if you have to install it yourself, you are more likely
> MF> to be in the line of communication to find out about updates as
> MF> well.
> 
> That is of course a concern. However, I assume that most distributions
> are pretty good at including bugfixes. Otherwise it is easy to find
> distributions with better policies.

Of course my opinion is that while getting included in the mainline
kernel is a nice milestone for asterisk as a whole, I don't think it is
important. If the driver development moved away from it's current build
on everything structure and moved to build on this current release, then
when the API changed, then asterisk would get tied to specific kernel
revs. Could you imagine the problem of saying asterisk release 1.4.25
only works with the following kernels, Debian 2.6.19-4, RHEL
2.6.19.whatever, Ubuntu 2.6.18-6, and so on. Identifying what patches
made it into a backport and which ones are sticking tightly to the
mainline kernel would become a support nightmare. 

If the goal is a better out of the box experience, then that person
needs to use a distro or similar that can install form a CD with near
zero interaction and not have to worry about any hardware or whatever
considerations. That isn't really the interest of this mailing list to
make the OSX like version of a linux distro for asterisk to sit on top
of so PHB type people can have simple interfaces to deal with. That is
more the interest of the surrounding community to package up what the
developers of asterisk have produced and made usable.   
-- 
Steven Critchfield <critch at basesys.com>