nextepc based LTE network @ CCCamp2019

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/nextepc@lists.osmocom.org/.

Sukchan Lee acetcom at gmail.com
Tue Aug 27 15:14:08 UTC 2019


See inline!

On Tue, Aug 27, 2019 at 11:40 PM Harald Welte <laforge at gnumonks.org> wrote:

> 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.
>

Ah! Now, I understand your intention. So I did rollback
ogs_expect_or_return().
Thank you for introducing a good interface.



> > 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...
>

Basically, I planned to implement HTTP/JSON for this part(e.g. GET /ue,
POST /logging). And also, I'd like to monitor the status in the WebUI.
However, to do so, we need to create one process to handle it. IMHO, it
will take a long to implement it. I also don't know which one is better for
us.


> > 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.
>

I saw your work! LOG macro with context adds the prefix logging. I will
refer your work when I improve a logging.

-- 
> - 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190828/c4ba2889/attachment.htm>


More information about the nextepc mailing list