I'm about to attach a patch for the dahdi startup script that automatically loads and unloads modules for hardware actually present on load and unload. As it stands the patch is ready for merging, there are however three more things to consider: 1. The checkconfig and dahdi_load_modules should perhaps be swapped around (this will give users the opportunity to "start" dahdi - load modules) which will then fail at checkconfig, giving the user to perform a dahdi_genconf (and fine tuning). 2. One could auto-generate /etc/dahdi/system.conf, this is however not as trivial as just running dahdi_genconf - it generates invalid configs when multiple ISDN cards are present, tonezone settings, E1 vs T1 (albeit, so far dahdi_genconf has gotten this pretty accurate permitting jumpers are set correctly), and then there is the issue of echocan (I like having oslec on analog lines and no echocan on isdn, others disagree on this). 3. Perhaps the loading/unloading/config generation should be in a separate startup script (eg, dahdi-modules which is set to "before dahdi" so that (a) - it becomes optional, and (b) a restart of dahdi won't trigger a full module unload/reload cycle). Please advice whether I'm wasting my time or whether this is something that may well get merged. Reproducible: Always
Created attachment 238635 [details, diff] dahdi.diff And the patch as promised.
Tony - any feedback on this? I'm tending towards a separate script, something like "dahdi-autoconf", this makes it easier for users to decide whether or not they want to actually use this or not, alternatively it needs to at the very least be protected with a "DAHDI_USE_AUTOCONF=no" in conf.d/dahdi IMHO. Please make a recommendation as to what you'd prefer so that I can continue working on this. I'd like to replace the dahdi_gen_conf with my own variant and this is as good a motivation as any. If you'd prefer to NOT carry this I can also make it an internal script for ULS and close this report. Please just push me in a direction. I don't really care which one. Going the "private" route has the advantage that it will be the separate startup script route, but I can maintain it internally for a few weeks/months before resubmitting here. The possible downside is less public testing. The advantage of separate script in itself is that no modifications are required to current scripts. The advantage of integrated (but filtered by default) is that it remains a single init script for dahdi. The downside is harder to just rerun dahdi_cfg without triggering a full module unload/load cycle (which already triggered a few kernel warnings on 2.4.0).
Created attachment 262091 [details] init.d/dahdi-autoconf I think I prefer this solution. It additionally auto generates an /etc/dahdi/system.conf which is based on my personal experience rather than the dahdi_gen_conf script (which I inevitably end up hacking a bit before it's usable, it should also not generate invalid "timing priority" values like the dahdi_gen_conf script). Features that are missing: * Support for PRI (both E1 and T1) * Ability to deal with LBO - although I suspect very few people will have longer than 133ft cables going to their NTUs). * Ability to set different parameters on different individual ports. The last point is slightly moot IMHO. The idea behind the script is to just make it easier, and for ULS it's specifically designed so I can change the hardware configuration on a box, reboot and have everything "just work". This script has just gone into our repository but I feel it's something that others will also find useful (I hope) and therefor would like to share it. The defaults should be sane, the options that I foresee people will want to change are configurable from conf.d/dahdi-autoconf and the conf.d/autoconf file is the one that I foresee that I will be using on all my installations (Yes, I try to keep these things as identical as possible from one install to the next). IMHO if you need to set per-port settings then you should classify yourself in the "super advanced" group of users and you really aught to NOT be using this script (or possibly use this once to generate a starting point and then hand-hack it anyway.
Created attachment 262093 [details] conf.d/dahdi-autoconf companion config file as promised.
Created attachment 268525 [details] init.d/dahdi-autoconf Updated init script. This just fixes a problem with configuring NT ports (a typo prevented the port number from being passed correctly), and an improved mechanism for actually obtaining the port number for each card. The wcb4xxp module named the cards in a fashion like "B4/0/4" which is basically B4/card/port which worked quite nicely for those cards, zaphfc (and others presumably too) does not, so instead count them manually by monitoring the "location" variable. All ports for a single location should always be successive, so there is no need to do anything more complex than a simple counter as long as the location doesn't change, and reset back to one when it does.
+*dahdi-tools-2.4.1 (21 Apr 2011) + + 21 Apr 2011; Tony Vroon <chainsaw@gentoo.org> +dahdi-tools-2.4.1.ebuild, + +files/dahdi-autoconf.conf, +files/dahdi-autoconf.init: + Maintenance release, adds support for kernels up to 2.6.38 and increases + compatibility with systems that can not support read-line multiple PCI + commands. Additional initscripts by Jaco Kroon, closes bug #328143. Compile & + install additional binaries, also by Jaco Kroon, closes bug #337472. With + thanks to Oliver Jaksch for alerting me to the new version in bug #357311.
