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