[asterisk-bugs] [Zaptel 0012405]: [patch] bad master selection (2 different ways)

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12405 
====================================================================== 
Reported By:                biohumanoid
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   12405
Category:                   zaptel (the module)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Zaptel Version:             1.4.9.2 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-10-2008 05:44 CDT
Last Modified:              04-14-2008 03:27 CDT
====================================================================== 
Summary:                    [patch] bad master selection (2 different ways)
Description: 
Current zaptel 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. ztdummy once loaded will be the master forever.
2. even not-running SPAN can be a master
3. master implementation is ugly...

====================================================================== 

---------------------------------------------------------------------- 
 biohumanoid - 04-14-08 03:27  
---------------------------------------------------------------------- 
>Does the ztdummy patch means that ztdummy would do nothing if there's any
other span?

Yes. ztdummy will not be a master, if there is any other non-alarm SPAN.



>Also, from a very short reading of your patch: what is "pref_master" (vs.
the existing "prefmaster")? 

zt_register with prefmaster != 0 can ask zaptel to make it's span the
master.

But we should device if later (in zt_checkmaster).

Any decision about master should be done at one function
(zt_checkmaster).



>Why not shoot higher, and make the extra parameter to zt_register the
span's priority?

1. I'm not sure that my vision is the same as yours.

2. I've made slightly modifications, to make it backward compatible.

3. I think it's a bad idea to pass priority in code.

It should be passed by special IOCTL (maybe via ZT_SPANCONFIG).

Thus, we should patch ztcfg, zaptel.h, zaptel-base.c

Also, it's a good idea to remove preferred master from code.



>There's a FIXME note you remove about locking. What do you do about
this?

Sorry, I haven't understood this.



>You reverted an old change to keep the newly-selected master in a
temporary variable new_master and left master set to NULL for a while.

As far as I understood, you are talking the first call zt_register will
not give us a master.

It's correct. zt_register CAN't provide us a master (SPAN is registered,
but NOT running...).

SPAN can be a master only after ioctl (ZT_STARTUP).



>check_master is callable from modules. What exactly do you assume about
locking when that route is used?



I've made this patch to check the idea.

If you thing my vision is the as yours - I'll cleanup the code. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-14-08 03:27  biohumanoid    Note Added: 0085438                          
======================================================================