Driver questions

[Sean Hinde]

Vance,

Thanks for the answers - my understanding is growing :)

> 	port_command = send
> 	port_control = ioctl

Yes, sure, but the crypto decided to use port_control for the work part, not
port_command. I guess both work so no difference?

> > Is the syncronous one quicker?
> 
> It looks to me like port_command (async) will be quicker.

I'm not sure I see this. Port_command relies on dropping a message into the
receive box of the process whereas port_control look closer to a straight
bif.

> 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.

I guess so. This also maps with the comments in the chapter on writing a new
distribution mechanism.

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

If I read io.c correctly in binary mode the return value is ignored (if
positive) because it is already encoded in the driver binary. In normal mode
a list is made from the resp buffer using the return value as its length. I
think I get this now..


> 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().

Oh yes, missed that one.

> > 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.

This is kind of what I thought from the docs but crypto seems to do it a
little differently.. Here there is a server process which opens the driver,
"owns" it, and puts the port reference in a 'protected' ets table (i.e. read
allowed by all). The client functions read this table and call
erlang:port_command in the context of the *calling* process. This avoids
message passing overhead completely. Maybe I just figured out the advantage
of port_control for my app..

> 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.

It would be nice if some of this understanding was published somewhere.
Maybe a use for the wikie?

Cheers,
Sean



NOTICE AND DISCLAIMER:
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.