Driver questions

[Vance Shipley]

Sean Hinde writes:

> 1. When to use synchronous port_control as opposed to asynchronous
> port_command and driver_output?

As I understand it, and indeed use it, port_command is for sending data
down the pipe (i.e. some payload data) while port_control is for doing
an "ioctl" on the device.  Either function could be used for either
purpose but port_command is well suited for sending data as can use
scatter gather (io_vec structures) while port_control has a clean
seperation between the command operation and the data for the operation.

While your application doesn't really fit into the communications channel
context if you think about the driver interface functions in this sense
it makes sense.

	port_command = send
	port_control = ioctl

["port_command" was an unfortunate name given the later addition of
 port_control]


> Is the syncronous one quicker?

It looks to me like port_command (async) will be quicker.


> 2. In using port control how big is the return buffer by default? Can this
> be relied on (it appears not to be documented)?

It is 64 bytes by default.  The code for port_control lives in
~/erts/emulator/beam/io.c and you'll find the size of the response hard
coded in there:
	    char port_result[64];       /* Buffer for result from port. */

I wouldn't rely on it, just check the actual size which is supplied in
the last argument to your driver's control function and make sure it's
large enough for the response.  If not allocate your own and return that.


> 3. What is the significance of the return value in the control case? Is it
> related to the length of the result?

>From my notes:
	You should return the number of bytes supplied in the response
	buffer or  -1 to indicate the command was not recognized.


> Is this different if PORT_CONTROL_FLAG_BINARY is set (as implied by a
> comment in crypto_drv.c)?

Well I just learned something new!  Having looked at the sources I see if
you want to return a binary you'll have to set the control flag for it.
In that case the comment in crypto_drv.c is correct:

/* Since we are operating in binary mode, the return value from control
 * is irrelevant, as long as it is not negative.
 */


> 4. Is it neccessary to create a driver binary for the return
> value as in the crypto case:

Since the crypto driver is using port_control in binary mode it creates
a binary for the response.

> Or can one just use a local variable as in Tobbes example:

The byteorder driver uses port_command.  You send backwards with one
of the functions:
	driver_output(ErlDrvPort port, char *buf, int len)
	driver_output2(ErlDrvPort port, char *hbuf, int hlen,
			char *buf, int len);
	driver_output_binary(ErlDrvPort port, char *hbuf, int hlen,
			ErlDrvBinary* bin, int offset, int len);
	driver_outputv(ErlDrvPort port, char* hbuf, int hlen, ErlIOVec *ev,
			int skip);

> Is the difference down to the choice of sync or async?

No, you can send back a binary with either case.  If you're using
port_command and want to return a binary then send it back with
driver_output_binary().

> 5. In both sync and async cases is it possible for any process to make use
> of the port and have answers returned directly, or only the process which
> opened the port?

Answers always go to the port owner.  You can change this with
port_connect/2.

> I have read the docs and pored over io.c but it would be nice to have some
> definitive answers


Please don't take my answers as "definitive", they just represent my
understanding of how things work after having spent some time working
on drivers.

	-Vance

Motivity Telecom Inc., Telephony Signaling Solutions
+1 519 579 5816