[asterisk-dev] [Code Review] 931: Remove 'chans' array from dahdi-base.c

[Shaun Ruffell]

> On April 11, 2013, 7:17 p.m., Alec Davis wrote:
> >

Sorry Alec,  I should had made it clear when I closed this that I was just removing some old cruft. These changes were released orignally in DAHDI-Linux 2.5...

The final commit of the series that removed it was http://git.asterisk.org/gitweb/?p=dahdi/linux.git;a=commit;h=579ea560efd7a82ac34ca211571ad426fff86c0d


- Shaun


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/931/#review8235
-----------------------------------------------------------


On April 11, 2013, 2:19 p.m., Shaun Ruffell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/931/
> -----------------------------------------------------------
> 
> (Updated April 11, 2013, 2:19 p.m.)
> 
> 
> Review request for Asterisk Developers and Tzafrir Cohen.
> 
> 
> Repository: DAHDI
> 
> 
> Description
> -------
> 
> This review is for the 11 commits on http://github.com/sruffell/dahdi-linux/tree/chan_list (b07adb15484398f8fb37...8425d20d6e84766590ec)  It completely removes the 'chans' array from dahdi-base.c, but keeps the external behavior the same, namely channels are numbered in registration order.
> 
> The point of these changes is to eventually support renumbering spans / channels on the fly as part of supporting hot pluggable spans, but this change set has the affect of reducing memory usage for small/normal installations (since arrays no longer need to be setup for spans and chans).
> 
> 
> Diffs
> -----
> 
>   linux/trunk/drivers/dahdi/dahdi-base.c 9390 
>   linux/trunk/include/dahdi/kernel.h 9390 
> 
> Diff: https://reviewboard.asterisk.org/r/931/diff/
> 
> 
> Testing
> -------
> 
> Again, hasn't gone through a complete regression, but I've been using it as the base for most of my work in order to ensure that there aren't any performance regressions.
> 
> With DAHDI_CHUNKSIZE == 8, the practical limit is still something under 1024 channels due to the masterspan processing overhead, but this change, in conjunction with some improvements/changes there (default CHUNKSIZE something other than 8? Reduced locking?) this could be part of a solution to allow more channels on a single system without recompiling.
> 
> 
> Thanks,
> 
> Shaun Ruffell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130411/9546420e/attachment.htm>