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

[Paul Cadach]

Hi,

Tzafrir Cohen wrote:
> We commited some code. Tested it on a Fedora system. Noticed Fedora did
> a little bit of backport of a tiny kernel feature. So their 2.6.18
> kernels actually behave like 2.6.19 . This is the thing that was
> commited into zaptel 2.6.13 .
>
> Oops. This badly broke people with real 2.6.18 kernels (I didn't notice
> this at first in this 2.6.18 Debian system, as debugfs is disabled
> there). No problem: reverted the situation in Zaptel branch 1.2 .

Each feature/API change SHOULD have its onw "flag" (#define somewhere) to 
allow to choose correct API usage.
Take look at chan_zap and zaptel/libpri/libss7 - chan_zap verifies presence 
of required feature by checking #defines come from zaptel/libpri/libss7.

> Only to get some complaints from a member of this list who uses some
> kernel 2.6.18 from Fedora Core 5. His post was responded with: "sure,
> zaptel with build with your kernel. Just apply this tiny patch".

Complain RedHat about non-flagged backports they perform and breaks 
compatibility. BTW, is the rest of zaptel compiling well? If so, Xorcom 
should take care about their xpp's drivers...

As a developer you cannot track all changes made in individual 
distributions, so you should have feedback channel from users who can notify 
you about a problems, then you should drill this case down until 
solution/workaround will be provided.

> So the net result is that installing Zaptel on your own remains a
> painful task.

Are you sure RedHat will not just disable building zaptel? If so, user will 
have much more pain to re-build kernel (most distributions have their own 
tricks to build kernel correctly). And, who can guarantee RedHat will 
perform consistancy checks when they do such backports? They can verify just 
parts needs to be build, nothing else.


WBR,
Paul.