[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