[erlang-questions] Passing parameters to a port driver

[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ó:
> 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ó:
>> Sebastian Bello <sebastian.bello@REDACTED> 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
>>
>> __________ NOD32 2933 (20080310) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
>>
>>   
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080311/bc4a2ec0/attachment.htm>