[OpenSER-Devel] Request for comment: module interface extension
Dan Pascu
dan at ag-projects.com
Mon Dec 17 16:41:04 UTC 2007
On Monday 17 December 2007, Bogdan-Andrei Iancu wrote:
> Hi Henning,
>
> yes, this is an idea that was discussed for some time, but without any
> clear results for implementation. It is a bit complex and we need to
> think it over and over to be sure we get it right. Let's not jump into
> action until everything is settled.
>
> Give me couple of days to go over this idea again and to dig for any
> previous notes on this matter.
>
> The first thing we need to clarify is how to pass an unlimited number
> of parameters:
> - via array, like main() does - but it might be too generic for our
> purposes
> - combination of fixed and additional parameters. The function will
> have the 2 fix params and any additional params will be passed as array
> - this will maintain some clarity (we still have the visible
> parameters), but also scalability.
I think there's another way. Practically speaking we do not need
an "unlimited" number or parameters (whatever that means on hardware that
is limited by nature). I do not expect anyone to export module functions
that need more than 5-7 parameters and if someone does I don't think we
want to have such functions available (just think what it means to
remember how to call a function with that many parameters).
What we can do is to use the standard C vararg mechanism to pass multiple
args. The script parser will impose a limit on how many arguments a
function can have (say 5-10). It will parse the script and build those
parameters from the function calls. Will fill the remaining unspecified
ones with NULL and call a function passing all those arguments.
Then the module can define functions using the ellipsis notation to
indicate they are prepared to accept a variable number of arguments.
A function with no arguments will be declared like:
static int function(struct sip_msg *msg, ...);
One that accepts 1 argument:
static int function(struct sip_msg *msg, char *arg1, ...);
and so on.
If a function has optional arguments it'll only declare the mandatory ones
and get the rest (if not NULL) using varargs (or we can still declare
multiple functions in the export structure as it does now). That way we
can have a single entry in cmd_export_t define a function with multiple
optional arguments and the function can determine itself if those
optional args are present or not at runtime.
The module cmd_export structure can contain a min/max number of args for a
function that allows the script parser to determine if a function is
suitable to be called in the given context.
This way we preserve function signatures, accept more than 2 arguments,
avoid extra parameters for functions that do not use them and it can
still be done with very little changes.
--
Dan
More information about the Devel
mailing list