Using (stripped down ei.h) with generic TCP instead of ports

Brett Hemes brhemes@REDACTED
Sat Sep 19 21:29:26 CEST 2020

Could you perhaps elaborate on your reply a bit?  The RT development environment (running in kernel mode) offers only a memory mapped interface besides the aforementioned UDP/TCP option for communication between the RT modules and user mode applications.  I believe “exposing the interface” would require me to both make an interface from scratch and then wrap it as a port driver or NIF to get it into the BEAM.  Aside from some arbitrary handshaking interface via registers I could imagine passing strings via fixed length character buffers but I will still need some form of encoding/decoding… which is how I ended up looking at the ei library.

Also, most of what I have read regarding Erlang seems to favor ports over drivers and NIFs as they better align with the Erlang philosophy but I am too new to all this to really know when each is preferred.

Thanks much,

From: Albin Stigö <albin.stigo@REDACTED>
Sent: Thursday, September 17, 2020 9:32 AM
To: Max Lapshin <max.lapshin@REDACTED>
Cc: Brett Hemes <brhemes@REDACTED>; Erlang Questions <erlang-questions@REDACTED>
Subject: [EXTERNAL] Re: Using (stripped down ei.h) with generic TCP instead of ports

I would expose the kernel code through a char or block device driver. There are already many facilities in most kernels for effective communication with userpace. a
After all, that's the whole point of a kernel...

On Thu, Sep 17, 2020, 16:00 Max Lapshin <max.lapshin@REDACTED<mailto:max.lapshin@REDACTED>> wrote:
Your idea is ok.  Just strip everything you don't need from ei and it will work for you.

As for me, I like enif api more, but Sverker has pointed that I'm misuing it inside drivers and it may break once =)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list