1

In the tutorial for erl_driver there seems to be no indication to where does the first ErlDrvPort object comes from. Say I want to wrap libusb-1.0 to use it from erlang. There is no place in the API described by ErlDrvEntry for any index methods. How does one find a port to open?

lonelyelk
  • 598
  • 9
  • 25

2 Answers2

2

Normally you obtain the first port using the erlang:open_port/2 function, usage of which is shown in the code example in section 6.2 of the tutorial you linked to in your question.

Steve Vinoski
  • 19,847
  • 3
  • 31
  • 46
  • It looks like they are hardcoding it inside of `driver_entry`. This line: `"example_drv", /* char *driver_name, the argument to open_port */` – lonelyelk Jan 23 '15 at 11:54
  • [Documentation](http://www.erlang.org/documentation/doc-5.6/erts-5.6/doc/html/driver_entry.html#extended_marker) is even less specific: `char *driver_name; /* name supplied as command in open_port XXX ? */`. **XXX ?** – lonelyelk Jan 23 '15 at 12:07
  • That string in the driver entry is the name of the driver. It might be helpful to look at a recently-implemented driver, such as [enm, the Erlang nanomsg driver](https://github.com/basho/enm). For example, [enm.erl lines 340-349](https://github.com/basho/enm/blob/master/src/enm.erl#L340-L349) use [`erl_ddll`](http://erlang.org/doc/man/erl_ddll.html) to load the driver shared library, and then [enm.erl line 443](https://github.com/basho/enm/blob/master/src/enm.erl#L443) calls `open_port` to ask the driver for a new port onto itself. (These line numbers are based on enm commit 65f278a.) – Steve Vinoski Jan 23 '15 at 19:14
  • Thank you, i see now. This is more of a design pattern question. In enm library examples the address (Url) is already known. What if you have to rely on the same c library to give you options on what address to use? It seems more natural to use one erlang port per one usb port. But then I would have to use another wrapper for examining usb devices' properties. Or I should use only one port that connects to libusb wrapper and implement some kind of protocol that can list as well as connect and transmit via casting `command` with some magic in first bytes? – lonelyelk Jan 24 '15 at 11:19
  • 1
    IMO using a control port (your second idea) is the right way to go. You can use `erlang:port_control/3` to implement a protocol to communicate with the driver over such a control port. – Steve Vinoski Jan 24 '15 at 16:14
0

Instead of using Ports to wrap a C library, you can also use NIFs. With Nifty there exists even a wrapper generator that does most of the work for you.

Andreas Löscher
  • 1
  • NIFs are more dangerous, because they can crash entire ErlangVM. For really short well tested code, they might be a good ieda. For wrapping entire library, it is better to stick with ports. – tkowal Jan 23 '15 at 11:03
  • NIF seems to be a good tool for isolated functions. Like when you need to make some calculations faster. – lonelyelk Jan 23 '15 at 12:03
  • Nifty has a "save execution" mode that runs the loaded nif in a separate node. If the library crashes, only the separated node crashes. This also solves the problem of blocking nif calls. (Only the separated node gets blocked) [relevant Nifty Tutorial page](http://parapluu.github.io/nifty/tutorial5/) – Andreas Löscher Jan 23 '15 at 13:35