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/.
Harald Welte laforge at gnumonks.orgHi 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)