[erlang-questions] Passing parameters to a port driver

[Sebastian Bello]

Hi list,

is there a way to pass parameters (maybe in the form of an Erlang term)
to a port driver while creating it (open_port)? My understanding is that
open_port launches the function
static ErlDrvData driver_start(ErlDrvPort port, char *buff)

on the port; what does "char *buff" contain?
Thanks,
Sebastian-

[Per Hedeland]

It's the complete Command string from open_port({spawn, Command}, ...) -
i.e. you can give that as "my_drv param1 param2" and the my_drv driver
will have its start() function invoked with that exact string as its
second argument (in C form of course:-). If you look at the
driver_entry(3) man page, the argument is called 'command', which
perhaps makes this a bit more obvious.

--Per Hedeland

[Sebastian Bello]

Per,
sorry but I didn't mention I was thinking about a linked-in driver; I read about extending the environment, but was wondering if it can be done by passing parameters; I guess the "char *buff" parameter on the C side must have that purpose.
    Sebastian-

Per Hedeland escribió:

It's the complete Command string from open_port({spawn, Command}, ...) -
i.e. you can give that as "my_drv param1 param2" and the my_drv driver
will have its start() function invoked with that exact string as its
second argument (in C form of course:-). If you look at the
driver_entry(3) man page, the argument is called 'command', which
perhaps makes this a bit more obvious.

--Per Hedeland
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions

__________ NOD32 2833 (20080129) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com



  

[Per Hedeland]

Sebastian Bello <sebasti...@inswitch.us> wrote:
>
>sorry but I didn't mention I was thinking about a linked-in driver;

You said "driver" which was quite sufficient - that was the case that my
answer described. (An external port program would (at least on *nix) get
the Command in the argc/argv arguments to main()...)

--Per

[Sebastian Bello]

There is no argc/argv in a linked in driver as far as I know. On the driver side you have

    static ErlDrvData driver_start(ErlDrvPort port, char *buff)

and buff just points to the driver name; if you load the driver with parameters you just get an "open_error".
Any other ideas?
    Sebastian-

Per Hedeland escribió:

You said "driver" which was quite sufficient - that was the case that my
answer described. (An external port program would (at least on *nix) get
the Command in the argc/argv arguments to main()...)

--Per
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions

__________ NOD32 2843 (20080201) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com



  

[Per Hedeland]

Sebastian Bello <sebasti...@inswitch.us> wrote:
>
>There is no argc/argv in a linked in driver as far as I know.

Hm, it was a while ago, but according to your quote I wrote:

>> (An external port program would (at least on *nix) get
>> the Command in the argc/argv arguments to main()...)

I'm sorry, but I'm quite unable to parse that as a claim that a driver
would get argc/argv, so I have no idea why you feel the need to state
that it doesn't. But you're quite correct of course.

> On the
>driver side you have
> static ErlDrvData driver_start(ErlDrvPort port, char *buff)

Exactly, and as I recall your question was what was in the "buff", which
I explained.

>and buff just points to the driver name;

It points to (a C-style copy of) whatever string you passed to
open_port/2. As far as open_port is concerned, the driver name ends at
the first space (which is quite analogous to / consistent with how the
string is parsed in the case of an external port program, though I
hesitate to mention it...).

> if you load the driver with
>parameters you just get an "open_error".

Please share the code that gives that result. Of course open_port
doesn't "load the driver", but I assume it's open_port you're talking
about - anyway that's what *I* am talking about. I'm successfully using
the technique I described in commercial product code - in fact it's used
in the OTP code too, e.g. in the dbg module.

>Any other ideas?

None needed.

--Per

[Sebastian Bello]

Hi Per,

thanks for your response.
Ideally I would like to perform something like

Port = open_port({spawn, "./mylib parm1 parm2"}, [])

at the Erlang side, and be able to parse parmN from the C side:

static ErlDrvData driver_start(ErlDrvPort port, char *buff) {
   
    // parse parameters from *buff
}

That's all; is that possible with a linked-in driver?
Thanks,
    Sebastian-


Per Hedeland escribió:

None needed.

--Per

__________ NOD32 2933 (20080310) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com



  

[Sebastian Bello]

It doesn't work with the environment either:
   Port = open_port({spawn, SharedLib}, [{env, [{"PARM1","p1"},{"PARM2","p2"},{"PARM3","p3"}]}]),
Sebastian-

Sebastian Bello escribió:

[Per Hedeland]

>Sebastian Bello <sebasti...@inswitch.us> wrote:
>
>Ideally I would like to perform something like
>
>Port = open_port({spawn, "./mylib parm1 parm2"}, [])
>

>at the Erlang side, and be able to parse /parmN /from the C side:

>
>static ErlDrvData driver_start(ErlDrvPort port, char *buff) {
>
> // parse parameters from *buff
>}
>
>That's all; is that possible with a linked-in driver?

Yes.

--Per