asterisk / dahdi-linux

This is the official dahdi-linux repository. All issues and PR should be raised here.
GNU General Public License v2.0
49 stars 71 forks source link

How to exclude drivers from being compiled? #68

Open ilko-t opened 4 days ago

ilko-t commented 4 days ago

Hi,

On many of our servers we require just basic dahdi support, as we don't have any of the hardware cards. Basically we need it for timing of meetme conferences and IAX2 interserver trunks. Additionally, it's also used to provide sources in order to compile Voicesync package used by Amfeltec PCIe timer cards.

Given all compilation issues with RedHat 9.x kernels and compatible dahdi releases lagging behind severally, I am looking for a way to exclude all unneeded drivers from being compiled, as that's where typically compilation fails when new RedHat minor version is out.

Would greatly appreciate any help with this.

Thanks

InterLinked1 commented 4 days ago

Hi,

On many of our servers we require just basic dahdi support, as we don't have any of the hardware cards. Basically we need it for timing of meetme conferences and IAX2 interserver trunks. Additionally, it's also used to provide sources in order to compile Voicesync package used by Amfeltec PCIe timer cards.

Asterisk supports multiple timing sources, you don't need DAHDI strictly for that. Meetme uses DAHDI for bridging but not timing necessarily, so I think that's what you're thinking of. If you use ConfBridge, DAHDI is not used for bridging.

Given all compilation issues with RedHat 9.x kernels and compatible dahdi releases lagging behind severally, I am looking for a way to exclude all unneeded drivers from being compiled, as that's where typically compilation fails when new RedHat minor version is out.

This sounds like an X Y problem to me...

I'm working on this now and hopefully there will be a PR up soon, but this is unfortunately the reality of using Redhat or one of its copycat distros that backports kernel features that are non-standard for particular kernel versions. I would suggest using Debian if you want a more stable DAHDI experience that doesn't suffer from that issue. There is no good reason to use Red Hat for a DAHDI system and plenty of downsides to doing so, just my opinion.

ilko-t commented 3 days ago

The choice of OS is not mine, it's company wide policy.

It's recommendation from asterisk developers to use res_timing_dahdi.so for heavy loads as ours, plus IAX2 trunking is something we use all the time. Same for many other systems where meetme hasn't yet been replaced by confbridge and the PCIe timer cards we use do need dahdi.

While I greatly appreciate you working on a fix for the current 9.5 RHEL amd the likes, I still need to account for the next 9.6 version which will likely cause the same issues given the mess RHEL are doing.

Back to the original question - is there a way to prevent majority if not all hardware card drivers from compiling?

Thanks

InterLinked1 commented 3 days ago

The choice of OS is not mine, it's company wide policy.

It's recommendation from asterisk developers to use res_timing_dahdi.so for heavy loads as ours, plus IAX2 trunking is something we use all the time.

IAX2 trunking doesn't depend on res_timing_dahdi either, it just needs one of the timing modules: https://docs.asterisk.org/Configuration/Core-Configuration/Timing-Interfaces/

But I can understand the desire to use DAHDI timing, especially if you have a good clock source there.

Same for many other systems where meetme hasn't yet been replaced by confbridge and the PCIe timer cards we use do need dahdi.

FYI, MeetMe is deprecated and could be removed any Asterisk version. The removal was suspended because some large company objected, but I don't imagine they'll hold up its removal forever.

While I greatly appreciate you working on a fix for the current 9.5 RHEL amd the likes, I still need to account for the next 9.6 version which will likely cause the same issues given the mess RHEL are doing.

Previously, I wasn't building Red Hat and friends in my CI so that was a blind spot for these issues happening. I was able to add some logic to use the kernel headers that were installed, even though they don't match the provided kernel, so I can now build DAHDI in those. I think if I add a -latest container for Rocky or Alma, that should hopefully catch these as they happen. I already do the same for the various kernels. And ultimately, these issues do need to be fixed by somebody. If something slips by, anyone is free to flag it for my attention too. Unless someone was using the new version in the first few days it came out, ideally the issue would be patched by the time they try.

Back to the original question - is there a way to prevent majority if not all hardware card drivers from compiling?

There seems to be a mechanism to selectively build subsets, but I don't think this is documented, at least as far as I know. Might be something you can pass to make but I haven't studied the makefiles enough.

You could try editing drivers/dahdi/Kbuild and commenting out the DAHDI_BUILD_ALL lines corresponding to drivers you don't need, and see if that works.

ilko-t commented 3 days ago

Appreciate you support, thanks