See inline!
On Tue, Aug 27, 2019 at 11:40 PM Harald Welte <laforge(a)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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)