[sr-dev] Forward declaration of SDPOPS functions in my module
Daniel-Constantin Mierla
miconda at gmail.com
Sat May 9 09:58:21 CEST 2015
Yes, you have to edit the code in sdpops module if you want to expose a
function from it for usage in another module.
You can make a pull request on github project for your patch to sdpops
module and if all is ok with it, will be merged as soon as master branch
in unfrozen.
Cheers,
Daniel
On 08/05/15 23:35, Cockhootec Yahrabee wrote:
> Daniel, I am sorry I am really confused right now because I read your
> responses again and it seems that I need to edit code of sdpops
> module. Is that right? Or I can extend sdpops API from outside like in
> my module? Could you please be specific?
>
> If I decide to extend sdpops API (right in the module - it seems to be
> pretty easy I just need to add function to structure and specify
> pointer to that function) should I commit it to kamailio/kamailio
> repository? Could you please send me some kind of link with guidelines
> for contributing?
>
> Thanks in advance
>
> On Fri, May 8, 2015 at 5:58 PM, Cockhootec Yahrabee
> <cockootec at gmail.com <mailto:cockootec at gmail.com>> wrote:
>
> Thanks Daniel for quick response.
> Could you please be more specific on how to extend "sdpops_api_t"
> structure?
>
> I've never done it so little help will be appreciated.
>
>
> On Fri, May 8, 2015 at 4:42 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
> On a quick look, sdpops already exposes a function via api --
> see modules/sdpops/api.h. So most of the needed things are
> there, you just need to extend the sdpops_api_t structure and
> bind_sdpops(...) function to set the new field to the function
> pointer.
>
> Cheers,
> Daniel
>
>
> On 08/05/15 16:37, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> practically you want to call a function from another compiled
>> object (like from a library). The way to do it is to expose
>> the function you want via an API structure and then bind to
>> this module from your module. This is quite common practice
>> in kamailio -- for example, a lot of modules connect to tm
>> module to use its functions.
>>
>> You can look at sl module how it exports some of its
>> functions (the structure sl_api_t and the function
>> sl_load_api) and then at registrar module to see how it bind
>> and uses the api from sl module.
>>
>> Cheers,
>> Daniel
>>
>> On 08/05/15 16:07, Cockhootec Yahrabee wrote:
>>> Hi guys,
>>>
>>> I found this very useful function in `sdpops` module which I
>>> want to use within my own module but I cannot find out how
>>> to forward its declaration correctly so I can use it in my
>>> module.
>>>
>>> Since `sdpops` has not defined it's functions within .h file
>>> I am just simply forward declaring function I want to use in
>>> my .h file like this:
>>>
>>> int sdp_remove_codecs_by_name(sip_msg_t* msg, str* codecs);
>>>
>>> And then I just calling it within my function. I can compile
>>> it and linker won't give me any errors but when I am running
>>> Kamailio it says that I have error in config file which is
>>> obviously not true because if I comment code which uses
>>> forward declared function kamailio runs without errors.
>>>
>>> Kamailio log (when using forwarded declaration of sdpops
>>> function):
>>> 0(23096) DEBUG: <core> [route_struct.c:129]: mk_action():
>>> ACTION_#2 #0/2: 3(3)/ 0x1
>>> 0(23096) DEBUG: <core> [route_struct.c:129]: mk_action():
>>> ACTION_#2 #1/2: 3(3)/ 0x1
>>> 0(23096) DEBUG: <core> [route_struct.c:129]: mk_action():
>>> ACTION_#16 #0/3: 22(16)/ 0x7f115fcfa898
>>> 0(23096) DEBUG: <core> [route_struct.c:129]: mk_action():
>>> ACTION_#16 #1/3: 8(8)/ 0x7f115fcfaf98
>>> 0(23096) DEBUG: <core> [route_struct.c:129]: mk_action():
>>> ACTION_#16 #2/3: 0(0)/ 0x7f1100000000
>>> 0(23096) DEBUG: <core> [route.c:129]: route_add(): mapping
>>> routing block (0xa84a40)[MANAGE_FAILURE] to 1
>>> ERROR: bad config file (1 errors)
>>> 0(23096) DEBUG: <core> [ppcfg.c:224]:
>>> pp_ifdef_level_check(): same number of pairing preprocessor
>>> directives #!IF[N]DEF - #!ENDIF
>>> 0(23096) DEBUG: tm [t_funcs.c:85]: tm_shutdown(): DEBUG:
>>> tm_shutdown : start
>>> 0(23096) DEBUG: tm [t_funcs.c:88]: tm_shutdown(): DEBUG:
>>> tm_shutdown : emptying hash table
>>> 0(23096) DEBUG: tm [t_funcs.c:90]: tm_shutdown(): DEBUG:
>>> tm_shutdown : removing semaphores
>>> 0(23096) DEBUG: tm [t_funcs.c:92]: tm_shutdown(): DEBUG:
>>> tm_shutdown : destroying tmcb lists
>>> 0(23096) DEBUG: tm [t_funcs.c:95]: tm_shutdown(): DEBUG:
>>> tm_shutdown : done
>>> 0(23096) DEBUG: <core> [mem/shm_mem.c:242]:
>>> shm_mem_destroy(): shm_mem_destroy
>>> 0(23096) DEBUG: <core> [mem/shm_mem.c:245]:
>>> shm_mem_destroy(): destroying the shared memory lock
>>>
>>> Did anybody resolved this issue? All help is appreciated.
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>> --
>> Daniel-Constantin Mierla
>> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
>> Kamailio World Conference, May 27-29, 2015
>> Berlin, Germany - http://www.kamailioworld.com
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
> Kamailio World Conference, May 27-29, 2015
> Berlin, Germany - http://www.kamailioworld.com
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150509/61cd1b2e/attachment-0001.html>
More information about the sr-dev
mailing list