[asterisk-bugs] [DAHDI-linux 0013205]: [patch] bad master selection

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13205 
====================================================================== 
Reported By:                biohumanoid
Assigned To:                kpfleming
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   13205
Category:                   dahdi (the module)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             2008-07-31 00:11 CDT
Last Modified:              2009-03-11 10:56 CDT
====================================================================== 
Summary:                    [patch] bad master selection
Description: 
Current dahdi master handling work in the following way:
The first SPAN become a master
If a new registered !!! SPAN is preferred , it is the new master
If a span is unregistered - the new master is the first available span
If master SPAN is in alarm state - the new master is the first non in
alarm state SPAN

So
1. dahdi-dummy once loaded will be the master forever.
2. even not-running SPAN can be a master
3. master implementation is ugly...
====================================================================== 

---------------------------------------------------------------------- 
 (0101540) sruffell (administrator) - 2009-03-11 10:56
 http://bugs.digium.com/view.php?id=13205#c101540 
---------------------------------------------------------------------- 
biohumanoid: I start with the assumption that we would like dahdi to always
be able to provide a source of timing for any conferences that are in
progress in the kernel, even if spans go into alarm.  If this is the case,
then I guess the discussion is moot.

biohumanoid> 1. You can load dahdy_dummy in /etc/init.d/dahdi

What is the best way for /etc/init.d/dahdi to determine when it should
load dahdi_dummy?  Currently the /proc/dahdi/ directory is checked for a
present span, but this can cause problems on reload if a user has a
reference open to /proc/dahdi (like it's their current directory) which
would prevent new files in that directory to not show up on reload.  Then
dahdi_dummy is reloaded anyway, registers a span that messes with the span
configuration.

biohumanoid> 2. You can load dummy from dahdi.ko with "request_module"

But if the module is loaded when the span goes into alarm, it seems like
it might lead to some tricky code to either determine when the system is
being started up (when their are often alarms as the framers are being
configured), or that dahdi_dummy.ko would just ended up being loaded by
request_module most of the time.

biohumanoid> 3. You can load dummy with udev rules

How could one use udev to load dahdi_dummy dynmically in response to an
alarm, unless there is a sysfs attribute used on spans to indicate when it
goes into alarm that could be monitored by udev?

If the functionality of dahdi_dummy is moved into the dahdi-base.c, it
wouldn't need to "tick" or consume CPU cycles unless it is actually the
source of timing, but it increase slightly the size of the dahdi.ko
file....but not by much. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-11 10:56 sruffell       Note Added: 0101540                          
======================================================================