nextepc based LTE network @ CCCamp2019

[Harald Welte]

Hi Sukchan,

On Tue, Aug 27, 2019 at 11:20:37PM +0900, Sukchan Lee wrote:

> I'm really surprising that nextepc can support such a large people.

What I'm personally quite happy is that I couldn't see any clear memory
leaks.  Knowing from experience, this is one of the hardest tasks in
development of complex C-language software.

> 1. ogs_expect()
> I think that ogs_expect() is really good starting point to remove
> unnecessary ogs_assert().
> So, I added my version in ogslib() repository as below.
> 
> #define ogs_expect(expr, fallback) \
>     do { \
>         if (ogs_likely(expr)) ; \
>         else { \
>             ogs_error("%s: Expectation `%s' failed.", OGS_FUNC, #expr); \
>             fallback; \
>         } \
>     } while (0)
> 
> Let me know if the above interface has a problem.

I don't see a problem, other than the code looking - from my point of view
"ugly".  having return statements inside a macro argument is highly unusual,
AFAICT.

Also, in your version, how would a "print a message but do nothing else" look like?
I think it would be "ogs_expect(ret == OGS_OK, );" where the empty second argument
looks completely unlike C code at all...

I understand your motivation and I was also thinking about something like this
originally, but I decided against it.  At least at the moment most of your
related functions return 'void' anyway, so my ogs_expect_or_return() worked fine.

I think as soon as you want to do something else but either nothing or return,
then you need to introduce a proper if-clause with error handling.  That's why
I introduced only those two versions and not a flexible variant.

> 2. VTY/CTRL
> I'm happy if nextepc can have such a good VTY/CTL. Indeed, this is actually
> needed if someone would like to test nextepc on a large scale.

As indicated, the question is whether I should simply start adding Osmocom VTY
using libosmocore, or if we should spend some more time looking for alternatives
or even designing + writing some new, better system and then introduce this to
nextepc.  I'm a bit undecided here at this point.  Take the quick route or the long
path...

> 3. Logging
> I agree that IMSI, APN context is needed when logging. So, I think
> mme_log()/sgw_log()/... needs to be introduced. And also, I saw a fix of
> the freeDiameter logging. How about merging it  to master branch. Please
> github pull request if you agree.

It's probably even more like a mme_ue_log() or something like that, because you
may have different objects/structs which provide loggign context.

In Osmocom we have introduced log macros like LOG_MSC_A(), LOG_MNCC_CALL(), lOG_MSUB()
where the first argument is typically the 'object' providing context.  Those macros then
expand to a call to the generic logging macro/function.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)