[asterisk-dev] dahdi_device representation

Shaun Ruffell sruffell at digium.com
Mon Aug 30 20:06:58 CDT 2010


On 8/30/10 6:45 PM, Oron Peled wrote:
> Another related stuff.
>
> I've looked into your "chan_list" git branch (yes, Tzafrir pushed me
> to do it...) and happily discovered it contains a huge ammount
> of important code cleanup (refactoring ioctl()'s into functions, using
> temporary "chan" variables, etc.)
>
> My suggestion is to push all code refactoring/cleanups ASAP to DAHDI
> trunk/ (just like the dahdi_span_ops re-org). That way, while we
> evaluate alternative channel mappings, our diffs will not be
> littered with pile of ugly old code.

I still have essentially one more question to answer before mirroring 
http://github.com/sruffell/dahdi-linux/tree/chan_list into a subversion 
team branch and asking for review.

There are two lines like: "struct dahdi_chan *const conf_chan = 
chans[ms->confna];" in __dahdi_process_getaudio_chunk and 
__dahdi_process_putaudio_chunk.  This is the "hot" path and I don't 
think it will be good to scan all the channels looking for that channel 
number.  It also isn't apparent to me all the semantics of how the 
confna parameter is used.  I currently believe that confna is used as a 
way to match up a conference to the pseudo channel where the mixing 
takes place, but I'm not yet sure.

So any suggestions about the best way to eliminate those two references 
to the chans[] array are welcome.  I'm currently *thinking* that a 
pointer to another channel needs to be added to 'struct dahdi_chan' and 
the first time that chans[chan->confna] is used, the known channels 
could be searched and a pointer saved.  But this adds a bit of redundant 
information.

But once those references are removed chan_by_num can be reimplemented 
as a search (like find_span is on the branch) and the dahdi_chan_reg and 
dahdi_chan_unreg can assign channel numbers by default the way the span 
registration does it on the branch (still in first come first serve 
basis).  Once *that* is done...then I think the channo/spanno can really 
be just aliases for the channels.

Oh, and since the DAHDI_CHANNO ioctl is still called on the pseudo 
channels, they will probably need their own range of numbers.  I'm 
thinking just to start their numbering at 65K or something.

Also, I can't merge anything into trunk until after the 2.4.0 release 
unless new issues come up in testing.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org



More information about the asterisk-dev mailing list