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

Which kernel are you using?

--Albin

On Sat, Sep 19, 2020, 21:29 Brett Hemes <[email protected]> wrote:

> 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,
>
> Brett
>
>
>
> *From:* Albin Stigö <[email protected]>
> *Sent:* Thursday, September 17, 2020 9:32 AM
> *To:* Max Lapshin <[email protected]>
> *Cc:* Brett Hemes <[email protected]>; Erlang Questions <
> [email protected]>
> *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...
>
>
>
> --Albin
>
> On Thu, Sep 17, 2020, 16:00 Max Lapshin <[email protected]> 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 =)
>
>
>
>
>
>