18 Nov
2008
18 Nov
'08
11:26 p.m.
Module: sip-router
Branch: andrei/mod_f_params
Commit: ca19a01ec657d1a431b1616a261a5a5f1d53a691
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=ca19a01…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Tue Nov 18 23:59:14 2008 +0100
mod if: more prototypes and defines
- prototypes for module (cmd_function) with 3, 4, 5, 6 and
variable number of parameters added. The 3-6 versions just extend the
old version with more char* parameters and are kamailio compatible.
The variable number of parameters function is something new and
experimental. It takes the sip_msg, the number of extra parameters
and an array of action_u_t values (the internal routing engine
parameters representation).
- added a magic value for the parameters numbers, to be used by
variable parameter functions (VAR_PARAM_NO)
- moved/added the NO_SCRIPT macro (parameters number magic value for
functions that should not be called from the script) from tm.
---
sr_module.h | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/sr_module.h b/sr_module.h
index 1301138..f2aea0e 100644
--- a/sr_module.h
+++ b/sr_module.h
@@ -44,6 +44,8 @@
* 2008-11-17 sip-router version: includes some of the openser/kamailio
* changes: f(void) instead of f(), free_fixup_function()
* dual module interface support: ser & kamailio (andrei)
+ * 2008-11-18 prototypes for various fixed parameters numbers module
+ * functions (3, 4, 5 & 6) and variable parameters (andrei)
*/
/*!
@@ -89,6 +91,15 @@
typedef struct module_exports* (*module_register)(void);
typedef int (*cmd_function)(struct sip_msg*, char*, char*);
+typedef int (*cmd_function3)(struct sip_msg*, char*, char*, char*);
+typedef int (*cmd_function4)(struct sip_msg*, char*, char*, char*, char*);
+typedef int (*cmd_function5)(struct sip_msg*, char*, char*, char*,
+ char*, char*);
+typedef int (*cmd_function6)(struct sip_msg*, char*, char*, char*,
+ char*, char*, char*);
+/* variable number of param module function, takes as param the sip_msg,
+ extra paremeters number and a pointer to an array of parameters */
+typedef int (*cmd_function_var)(struct sip_msg*, int no, action_u_t* vals );
typedef int (*fixup_function)(void** param, int param_no);
typedef int (*free_fixup_function)(void** param, int param_no);
typedef int (*response_function)(struct sip_msg*);
@@ -114,6 +125,13 @@ typedef unsigned int modparam_t;
typedef int (*param_func_t)( modparam_t type, void* val);
+/* magic parameter number values */
+
+#define NO_SCRIPT -1 /* export not usable from scripts */
+#define VAR_PARAM_NO -128 /* function has variable number of parameters
+ (see cmd_function_var for the prototype) */
+
+/* functions flags */
#define REQUEST_ROUTE 1 /* Function can be used in request route blocks */
#define FAILURE_ROUTE 2 /* Function can be used in reply route blocks */
#define ONREPLY_ROUTE 4 /* Function can be used in on_reply */
20 Nov
20 Nov
4:46 p.m.
New subject: [SR-Dev] git:sip-router: mod if: more prototypes and defines
On Nov 19, 2008 at 00:26, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:
[...]
mod if: more prototypes and defines
- prototypes for module (cmd_function) with 3, 4, 5, 6 and
variable number of parameters added. The 3-6 versions just extend the
old version with more char* parameters and are kamailio compatible.
The variable number of parameters function is something new and
experimental. It takes the sip_msg, the number of extra parameters
and an array of action_u_t values (the internal routing engine
parameters representation).
- added a magic value for the parameters numbers, to be used by
variable parameter functions (VAR_PARAM_NO)
- moved/added the NO_SCRIPT macro (parameters number magic value for
functions that should not be called from the script) from tm.
Example for a variable number of parameters function:
static cmd_export_t cmds[]={
{"print", print_f_0, 0, 0, REQUEST_ROUTE}, // overload test
{"print", print_f_1, 1, print_fixup_f_1, REQUEST_ROUTE},
{"print", print_f_2, 2, print_fixup_f_2, REQUEST_ROUTE},
{"print", (cmd_function)print_f_var, VAR_PARAM_NO, 0, REQUEST_ROUTE},
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{0, 0, 0, 0, 0}
};
...
static int print_f_var(struct sip_msg* msg, int no, action_u_t* vals)
{
int r;
for (r=0; r<no; r++)
printf("%s", vals[r].u.string);
printf("\n");
return 1;
}
You can have fixups too, I omitted them for simplicity.
Andrei
5:02 p.m.
New subject: [SR-Dev] git:sip-router: mod if: more prototypes and defines
On Thursday 20 November 2008, Andrei Pelinescu-Onciul wrote:
[..]
Example for a variable number of parameters function:
static cmd_export_t cmds[]={
{"print", print_f_0, 0, 0, REQUEST_ROUTE}, // overload test
{"print", print_f_1, 1, print_fixup_f_1, REQUEST_ROUTE},
{"print", print_f_2, 2, print_fixup_f_2, REQUEST_ROUTE},
{"print", (cmd_function)print_f_var, VAR_PARAM_NO, 0, REQUEST_ROUTE},
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{0, 0, 0, 0, 0}
};
Hi Andrei,
thank you for providing this. I found working with a bunch of function
parametern is much more natural then providing different "avp_foo" variables
that are used in other modules as a workaround. Where one should check for a
valid number of parameters when this VAR_PARAM_NO is used? In the fixup
function, or the function implementation?
Cheers,
Henning
5:43 p.m.
New subject: [SR-Dev] git:sip-router: mod if: more prototypes and defines
On Nov 20, 2008 at 18:02, Henning Westerholt <henning.westerholt(a)1und1.de> wrote:
On Thursday 20 November 2008, Andrei Pelinescu-Onciul
wrote:
In the implementation is easier.
In the fixup is possible, but would require using something like:
action_u_t* pno = (char*)param - &(((action_u_t*)0)->u.string) -
(param_no+1)*siezof(action_u_t);
parameter_no=pno->u.number.
(for static int print_fixup_f_2(void **param, int param_no)).
Another nicer way to do it is:
pno=fixup_get_param(param, param_no, -1);
parameter_no=pno->u.number;
(all this takes into accounts that the fixup functions get a pointer
to an action_u_t u.string member and that before the parameters
the number of parameters is stored, slightly different than kamailio)
We could make a macro for it to hide the ugliness and param. arrays
implementation details.
Andrei
[..]
Example for a variable number of parameters function:
static cmd_export_t cmds[]={
{"print", print_f_0, 0, 0, REQUEST_ROUTE}, // overload test
{"print", print_f_1, 1, print_fixup_f_1, REQUEST_ROUTE},
{"print", print_f_2, 2, print_fixup_f_2, REQUEST_ROUTE},
{"print", (cmd_function)print_f_var, VAR_PARAM_NO, 0, REQUEST_ROUTE},
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{0, 0, 0, 0, 0}
};
Hi Andrei,
thank you for providing this. I found working with a bunch of function
parametern is much more natural then providing different "avp_foo" variables
that are used in other modules as a workaround. Where one should check for a
valid number of parameters when this VAR_PARAM_NO is used? In the fixup
function, or the function implementation? 
5:59 p.m.
New subject: [SR-Dev] git:sip-router: mod if: more prototypes and defines
On 11/20/08 19:43, Andrei Pelinescu-Onciul wrote:
On Nov 20, 2008 at 18:02, Henning Westerholt
<henning.westerholt(a)1und1.de> wrote:
as we got into this discussion, for the future, it may make sense to
call the fixup with the array of the parameters and the number of
parameters - the fixup will iterate through parameters. Some times,
depending on the number of parameters, the meaning can change, or based
on the values of couple of the parameters we can do some optimizations.
Now calling the fixup for each parameter is a bit inconvenient from this
perspective, IMHO.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
On Thursday 20 November 2008, Andrei
Pelinescu-Onciul wrote:
In the implementation is easier.
In the fixup is possible, but would require using something like:
action_u_t* pno = (char*)param - &(((action_u_t*)0)->u.string) -
(param_no+1)*siezof(action_u_t);
parameter_no=pno->u.number.
(for static int print_fixup_f_2(void **param, int param_no)).
Another nicer way to do it is:
pno=fixup_get_param(param, param_no, -1);
parameter_no=pno->u.number;
(all this takes into accounts that the fixup functions get a pointer
to an action_u_t u.string member and that before the parameters
the number of parameters is stored, slightly different than kamailio)
We could make a macro for it to hide the ugliness and param. arrays
implementation details.
[..]
Example for a variable number of parameters function:
static cmd_export_t cmds[]={
{"print", print_f_0, 0, 0, REQUEST_ROUTE}, // overload test
{"print", print_f_1, 1, print_fixup_f_1, REQUEST_ROUTE},
{"print", print_f_2, 2, print_fixup_f_2, REQUEST_ROUTE},
{"print", (cmd_function)print_f_var, VAR_PARAM_NO, 0, REQUEST_ROUTE},
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{0, 0, 0, 0, 0}
};
Hi Andrei,
thank you for providing this. I found working with a bunch of function
parametern is much more natural then providing different "avp_foo" variables
that are used in other modules as a workaround. Where one should check for a
valid number of parameters when this VAR_PARAM_NO is used? In the fixup
function, or the function implementation?
9:06 p.m.
New subject: [SR-Dev] git:sip-router: mod if: more prototypes and defines
A few corrections (inline).
On Nov 20, 2008 at 18:43, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:
On Nov 20, 2008 at 18:02, Henning Westerholt
<henning.westerholt(a)1und1.de> wrote:
^^^^^^^^^
it should be only param_no (because the param. no
starts from 1 and not from 0)
On Thursday 20 November 2008, Andrei
Pelinescu-Onciul wrote:
In the implementation is easier.
In the fixup is possible, but would require using something like:
action_u_t* pno = (char*)param - &(((action_u_t*)0)->u.string) -
(param_no+1)*siezof(action_u_t); [..]
Example for a variable number of parameters function:
static cmd_export_t cmds[]={
{"print", print_f_0, 0, 0, REQUEST_ROUTE}, // overload test
{"print", print_f_1, 1, print_fixup_f_1, REQUEST_ROUTE},
{"print", print_f_2, 2, print_fixup_f_2, REQUEST_ROUTE},
{"print", (cmd_function)print_f_var, VAR_PARAM_NO, 0, REQUEST_ROUTE},
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{0, 0, 0, 0, 0}
};
Hi Andrei,
thank you for providing this. I found working with a bunch of function
parametern is much more natural then providing different "avp_foo" variables
that are used in other modules as a workaround. Where one should check for a
valid number of parameters when this VAR_PARAM_NO is used? In the fixup
function, or the function implementation? parameter_no=pno->u.number.
(for static int print_fixup_f_2(void **param, int param_no)).
Another nicer way to do it is:
pno=fixup_get_param(param, param_no, -1);
^^^^^^^^^^^^^^^^^^^^
that's wrong it should be
fixup_get_param(param, param_no, 0)
parameter_no=pno->u.number;
(all this takes into accounts that the fixup functions get a pointer
to an action_u_t u.string member and that before the parameters
the number of parameters is stored, slightly different than kamailio)
We could make a macro for it to hide the ugliness and param. arrays
implementation details.
There is already a function that does this:
fixup_get_param_count(void** cur_param, int cur_param_no)
returns the number of parameters on success or -1 on error
(but it can't fail so -1 is for future use).
Andrei
5652
days inactive
5654
days old
5 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt