Summary:ASTERISK-04078: [patch] Zaptel Init Updates
Reporter:damin (damin)Labels:
Date Opened:2005-05-04 18:23:33Date Closed:2011-06-07 14:10:17
Versions:Frequency of
Environment:Attachments:( 0) zaptel-init-gjb.patch.txt
( 1) zaptel-init-head-gjb.patch.txt
Description:Updates the zaptel.init to provide more intelligent debugging output when attempting to start zaptel, and replaced "insmod" with "modprobe" for more intelligent loading.


This hasn't been touched in a while, and in bringing up a new box, I got kind of annoyed that the zaptel script would just exit without any information telling you what was wrong. This also will help people understand that on redhat systems they need an /etc/sysconfig/zaptel file setup.
Comments:By: Kevin P. Fleming (kpfleming) 2005-05-04 20:37:32

This patch does not apply properly to Zaptel CVS HEAD.

By: damin (damin) 2005-05-04 21:57:50

Patch uploaded for CVS-HEAD. Seems to work on my test box.

By: Jeffrey C. Ollie (jcollie) 2005-05-05 13:54:19

1) The 2nd patch that you posted does not replace insmod with modprobe (a change which I agree with).

2) Could we conditionalize the debug output?  Perhaps only if DEBUG=yes would these new debug messages be printed.

By: Mark Spencer (markster) 2005-05-05 14:05:25

We should NOT use modprobe instead of insmod because when you use modprobe, that will trigger ztcfg, which shouldn't run until the last module is loaded and zaptel is ready.

By: Jeffrey C. Ollie (jcollie) 2005-05-05 14:53:37

Then use "modprobe --ignore-install".  On the systems that I run (admittedly few) using insmod in the zaptel.init fails and the modules don't load.  Personally, I don't add the post-install stuff to /etc/modprobe.conf.  Mainly it's because I always build RPMs and trying to edit a file during the RPM install is not something that you want to do.  Except for the "options torisa" and the "alias char-major-196" I don't think that the modprobe.conf stuff is necessary.

By: damin (damin) 2005-05-05 15:13:08

Zaptel-STABLE uses insmod.

Zaptel-HEAD uses modprobe. In fact, it loads Zaptel using modprobe first.

if [ $system = debian ]; then
   echo -n "Loading zaptel framework: "
   modprobe zaptel >& /dev/null && echo -n "done"
   echo "."
elif [ $system = redhat ]; then
   action "Loading zaptel framework: " modprobe zaptel

This can be re-worked a bit and cleaned up, but let's go through the logical progression:

1. Load Zaptel w/ Insmod
2. Load Hardware Drivers in order specificed in $MODULES variable
3. Verify that some hardware modules exist
4. Run ztcfg

I can clean up the scripting a bit and make it more consistend, and add a sample file for the /etc/sysconfig/file.

By: Kevin P. Fleming (kpfleming) 2005-05-15 00:58:56

It's not necessary to worry about an "install" action for zaptel.ko, because the Zaptel Makefile doesn't add one to modules.conf. It only adds them for the individual device drivers, not for the core. Thus, using 'modprobe zaptel' is safe.

Given that the script will run ztcfg, I think jcollie's suggestion of using --ignore-install for loading the device drivers is acceptable. If someone loads one outside the init script, ztcfg will still be run as expected.

By: Olle Johansson (oej) 2005-06-05 17:01:57

Where are we with this open issue report?


By: Michael Jerris (mikej) 2005-06-23 14:22:28

suspending pending updated patches.  Please re-open when you have updates.