[asterisk-dev] Kernel modules => mainline kernel

[Oron Peled]

On Monday, 12 בFebruary 2007 02:56, Paul Cadach wrote:
> +1. Keeping fastly growing asterisk/zaptel project in sync with much slower
> kernel is a headache.

Calling the general kernel development "much slower" than zaptel (not
asterisk) must be some private joke (you are invited to read lkml for a
few days to understand what I mean).

One of the problematic side effects of this change rate is that internal
kernel API's often break. This does not pose a serious problem for "in-tree"
drivers, since they get updated with the rest of the kernel.

However, out of tree drivers (like zaptel) suffer a lot of breakage
due to these changes and are sure to have more problems in the
short future (e.g: if/when the new interrupt handler API is
merged).

These problems are made more acute by distributions who backports
some features, notably RHEL/Fedora. Examples: gfp_t was introduced
around 2.6.12 but was backported by RH to 2.6.9, workqueue API
change was introduced in 2.6.20 but was backported by Fedora to 2.6.19.

[note: I'm personally a happy Fedora user, so I'm not bashing them for
       their own valid decisions, only pointing that *out of tree*
       drivers are always chasing the taillights in this scenario].

> Also, zaptel is mostly asterisk-related project, so it  
> is not required for 90% of Linux kernel users.

IMHO you are looking at this from the wrong POV. If zaptel was in
mainline kernel. 90% of *asterisk* users would not have to install
any driver for their hardware to work out of the box (the 10% are
those with special needs, e.g: developers). IMO, hardware should just
work out of the box.

Disclaimer: I'm biased as the one responsible for the xpp drivers
            (including the bugs).

-- 
Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
ICQ UIN: 16527398

"The future is here,  it's just not evenly distributed yet." 
        - William Gibson