Driver questions

[Raimo Niskanen]

Sean Hinde wrote:
> 
> > 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.
> 
> Hmm, I just made a driver which does both mechanisms and the one which does
> port_control in the calling process averages 20uS per call but the one which
> uses driver_output averages about 35uS.
> 

I would just like to mention that when a process calls port_command, the
->output code in the driver is executed, (perhaps) an answer is
generated and placed in the process's receive queue. Then port_command
returns and the process does a receive, which matches out the answer
from the receive queue. This implies more overhead than port_control,
which is just a BIF call that delivers the return value.

Also, port_command involves some more treatment of the buffer passed
down, to cope with the cases of the driver having an ->outpuv function,
etc. In this respect port_control is very starightforward.

And, port_control also have less overhead when returning data, at least
in the case when the data is less than 64 bytes (which you cannot rely
on).

The backdraws of port_command is that it is more limited, e.g no
vectorized output, cannot return binaries with list head
(driver_output2()), _cannot_ return an asynchronous reply, and certanly
more...

/ Raimo Niskanen, Ericsson UAB, Erlang/OTP