Driver questions

Sean Hinde Sean.Hinde@REDACTED
Wed Jun 27 15:47:02 CEST 2001


I have a short piece of C code which calculates a checksum and I want to
turn it into a driver. I have inserted it into the byteorder-1.0 contrib and
all works fine.

I have some questions though about the design choices involved in this.

1. When to use synchronous port_control as opposed to asynchronous
port_command and driver_output? I notice that Tobbe uses the second version
in the byteorder contrib, but the crypto application uses the first version.
Is the syncronous one quicker? What else should I take into account for this
type of application (as opposed to natively async stuff like ip drivers)?

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

3. What is the significance of the return value in the control case? Is it
related to the length of the result? Is this different if
PORT_CONTROL_FLAG_BINARY is set (as implied by a comment in crypto_drv.c)?

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

case DRV_INFO:
	*rbuf = (char*)(b = driver_alloc_binary(NUM_CRYPTO_FUNCS));
	for (i = 0; i < NUM_CRYPTO_FUNCS; i++) {
	    b->orig_bytes[i] = i + 1;

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

char lsb[]="l";
char msb[]="m";

if (*(char *) &endian)
  driver_output(erlang_port, lsb, sizeof(lsb));
  driver_output(erlang_port, msb, sizeof(msb));

Is the difference down to the choice of sync or async? Or something else?

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?

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

Thanks in advance,

- Sean

This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.

More information about the erlang-questions mailing list