<div dir="ltr"><div dir="ltr">See inline!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 27, 2019 at 11:40 PM Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sukchan,<br>
<br>
On Tue, Aug 27, 2019 at 11:20:37PM +0900, Sukchan Lee wrote:<br>
<br>
> I'm really surprising that nextepc can support such a large people.<br>
<br>
What I'm personally quite happy is that I couldn't see any clear memory<br>
leaks. Knowing from experience, this is one of the hardest tasks in<br>
development of complex C-language software.<br>
<br>
> 1. ogs_expect()<br>
> I think that ogs_expect() is really good starting point to remove<br>
> unnecessary ogs_assert().<br>
> So, I added my version in ogslib() repository as below.<br>
> <br>
> #define ogs_expect(expr, fallback) \<br>
> do { \<br>
> if (ogs_likely(expr)) ; \<br>
> else { \<br>
> ogs_error("%s: Expectation `%s' failed.", OGS_FUNC, #expr); \<br>
> fallback; \<br>
> } \<br>
> } while (0)<br>
> <br>
> Let me know if the above interface has a problem.<br>
<br>
I don't see a problem, other than the code looking - from my point of view<br>
"ugly". having return statements inside a macro argument is highly unusual,<br>
AFAICT.<br>
<br>
Also, in your version, how would a "print a message but do nothing else" look like?<br>
I think it would be "ogs_expect(ret == OGS_OK, );" where the empty second argument<br>
looks completely unlike C code at all...<br>
<br>
I understand your motivation and I was also thinking about something like this<br>
originally, but I decided against it. At least at the moment most of your<br>
related functions return 'void' anyway, so my ogs_expect_or_return() worked fine.<br>
<br>
I think as soon as you want to do something else but either nothing or return,<br>
then you need to introduce a proper if-clause with error handling. That's why<br>
I introduced only those two versions and not a flexible variant.<br></blockquote><div><br></div><div>Ah! Now, I understand your intention. So I did rollback ogs_expect_or_return().</div><div>Thank you for introducing a good interface.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 2. VTY/CTRL<br>
> I'm happy if nextepc can have such a good VTY/CTL. Indeed, this is actually<br>
> needed if someone would like to test nextepc on a large scale.<br>
<br>
As indicated, the question is whether I should simply start adding Osmocom VTY<br>
using libosmocore, or if we should spend some more time looking for alternatives<br>
or even designing + writing some new, better system and then introduce this to<br>
nextepc. I'm a bit undecided here at this point. Take the quick route or the long<br>
path...<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 3. Logging<br>
> I agree that IMSI, APN context is needed when logging. So, I think<br>
> mme_log()/sgw_log()/... needs to be introduced. And also, I saw a fix of<br>
> the freeDiameter logging. How about merging it to master branch. Please<br>
> github pull request if you agree.<br>
<br>
It's probably even more like a mme_ue_log() or something like that, because you<br>
may have different objects/structs which provide loggign context.<br>
<br>
In Osmocom we have introduced log macros like LOG_MSC_A(), LOG_MNCC_CALL(), lOG_MSUB()<br>
where the first argument is typically the 'object' providing context. Those macros then<br>
expand to a call to the generic logging macro/function.<br></blockquote><div><br></div><div>I saw your work! LOG macro with context adds the prefix logging. I will refer your work when I improve a logging.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" rel="noreferrer" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
</blockquote></div></div>