[asterisk-scf-dev] Code Review Emails

[David Boyes]

On 1/21/11 5:19 PM, "Kevin P. Fleming" <kpfleming at digium.com> wrote:
>
>If enough people feel they are 'noise' and would like them elsewhere,
>we'll move them. 

Fair enough. The announcement kinda appeared out of the blue with no
discussion here, so I thought I'd speak up.

>This discussion also occurred on the asterisk-dev list
>when ReviewBoard was put in place, and the consensus was to leave them
>there so that everyone could see the development discussion that was
>going on.

Didn't see that, so can't comment on it.

I guess I draw a distinction between discussion of objectives and thinking
and commit notifications and semi-automated notifications that such a
discussion has occurred. I personally would much rather have those thought
discussions in plaintext email, but c'est la vie. I guess this is one of
the downsides to these kinds of tools. Whatever. I'd rather have the
automated stuff elsewhere because it's hard to parse, but you already knew
that. 

I have a suggestion: can you direct the automated stuff through another
list and subscribe this list to it in digest mode? One message a day with
such stuff would be a lot less annoying than 7 in the last 30 minutes.
Those of you who want the single updates in real-time can use the RSS feed
or subscribe directly to the commits list; the rest of us can get the
periodic summary mail without having to cope with a zillion messages a day
that have a few lines of comments on a document that not everyone has
seen. 

>
>> BTW: I have clean builds of Asterisk SCF components on s390x and
>> power[5-7] CPUs. I will do some cleanup on the modifications -- but some
>> involve some assembler bits. Should we think about establishing some
>>kind
>> of architecture-dependent tree for such things, ie an arch/i686,
>> arch/s390x, arch/power7 structure?
>
>Well... we'd prefer not to have to require such things if at all
>possible. What areas of the system did you have to do this in? Are these
>on Linux or some other platform?

Linux on Z and Power, and AIX on Power. I'll put together a complete list
while I'm doing my cleanup.

It's not really a requirement for "average" hardware, but I've been doing
some pretty intensive profiling on the SCF code, and there are a bunch of
places that the C/C++ version works well-enough for demonstration
purposes, but profiles poorly for large-scale n-way systems or
shared-resource/partitioned/virtualization systems. On those systems,
these bits are more efficient with a little assembler support.

One area I encountered problems is where I'm interfacing with 40G and 100G
Ethernet hardware; the traffic classification code and channel management
code could use some help at those speeds. Admittedly, a fairly extreme
case for right now, but that kind of hardware isn't far off the horizon if
SCF is going to appeal to carriers.

I'm also working on segregating R/O and R/W data structures to make SCF a
little easier to put into those platforms equivalent of shared PROMs to
optimize memory utilization, which involves adjusting the kernel's
assumptions about where the data stack for the processes lives. This is
not easily done from HLLs.

So, I'm raising the point before I get your repository all dirty. If the
goal is "no assembler" then I can fall back to the C/C++ implementation
and see what can be done with optimizing the code there, but that makes
this a lot less interesting in that there's only so much that can be done
at the HLL level.