[erlang-questions] driver interfaces

Heinrich Venter <>
Sun May 13 11:39:39 CEST 2007

Hi all


I just want to make sure that I understand the driver interface basics



Takes iodata as data

Delivers to the output callback as binary or array

Returns values asynchronously with a driver_output call

-If the outputv callback is set, this is used instead and delviers the data
as ErlIOVec (which is faster)



Takes iodata as data

Delivers to the controll callback as binary or array

Returns values synchronously with results in the supplied rbuf parameter

-Return values may be either eterm format or binary

-Fastest according to docs



Takes an erlang term as data

Delivers to the call callback as pointer to eterm

Returns values synchronously with results in the rbuf parameter

-Return values must be in eterm format


It would seem that each has its own uses.

driver_controll is useful for exposing C  functions most directly.  For this
the calling erlnang code should send a binary, packed with the parameters in
the native format.  Returned values will be a binary, again in the native


driver_call is useful if you want to create functions that look more like
erlang functions than C functions.  You have to decode the sent terms and
encode the responses through ei.


driver_command is useful if you need to do asynchronous calls.  Perhaps also
useful in a multithreaded driver that does long computations (in combination
with driver_async)?


Some things I don't quite understand:

Is the output callbacks format also determined by set_port_controll_flags
like form the controll callback?


Might it be useful to have a controll type callback that delivers the data
as ErlIOVec, for the same optimisation reasons as for the output callback?


Is driver_output2 useful?  Is there an efficeincy issue with matching on a
binary on the erlang side, or does this function predate binary matching?


Is it more efficeint to use driver_output_binary than driver_output if it is
known beforehand that the port is in binary mode?


Any further insights would be appreciated



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070513/43a53867/attachment.html>

More information about the erlang-questions mailing list