Closed bhuztez closed 9 years ago
@bhuztez, can you please elaborate what this change is about? Why do you need to implement these as "port drivers" on OSv?
@penberg Erlang port is just an OS process. Each Erlang port has its corresponding Erlang process called port owner. Other Erlang processes communicate with an Erlang port via its port owner. And a port owner send data to the stdin of its Erlang port and receive data from the stdout of its Erlang port.
The problem is that it would fail to start an Erlang port on OSv, since fork is not supported. Because Erlang ports would have different stdin and stdout than each other, simply replacing exec() with osv::run() won't work as expected.
Instead of OS process, port driver is a library containing a set of callback functions. From port owner's point of view, ports and port drivers are very similar. By replacing ports with port drivers, only a small part of Erlang code has to be changed. I think this is the best way to support functionality provided by Erlang ports right now.
On Fri, Apr 24, 2015 at 9:36 AM, bhuztez notifications@github.com wrote:
@penberg https://github.com/penberg Erlang port is just an OS process. Each Erlang port has its corresponding Erlang process called port owner. Other Erlang processes communicate with an Erlang port via its port owner. And a port owner send data to the stdin of its Erlang port and receive data from the stdout of its Erlang port.
The problem is that it would fail to start an Erlang port on OSv, since fork is not supported. Because Erlang ports would have different stdin and stdout than each other, simply replacing exec() with osv::run() won't work as expected.
Hi, thanks for the explanation (and sorry about the delay).
Instead of OS process, port driver is a library containing a set of callback functions. From port owner's point of view, ports and port drivers are very similar. By replacing ports with port drivers, only a small part of Erlang code has to be changed. I think this is the best way to support functionality provided by Erlang ports right now.
I guess this makes sense, so I'll commit your change. I'm not sure this is a viable approach in the long run (will you have to do this for many ports?) but I guess if this is important in the long run we can come up with a different solution later.
Nadav Har'El nyh@cloudius-systems.com
Unfortunately, it doesn't seem to build properly now:
$ scripts/build image=erlang
...
make[1]: Leaving directory '/home/nyh/osv/apps/erlang/os_mon'
mkdir -p /home/nyh/osv/apps/erlang/ROOTFS/usr/lib64/erlang/lib/os_mon-2.3
cd os_mon; cp --parents -u -r -t /home/nyh/osv/apps/erlang/ROOTFS/usr/lib64/erlang/lib/os_mon-2.3 ebin/* src/* priv/*
cp: failed to get attributes of 'src': No such file or directory
Makefile:23: recipe for target 'install' failed
make: *** [install] Error 1
@nyh
I found tthe problem. src
is listed in osv-apps/.gitingore
. so the whole directory is ignored by git.
I will make another pull request to fix this.
Oh... So please undo my change of src to c_src in the Makefile in your pull request.
On Mon, May 4, 2015 at 11:58 AM, bhuztez notifications@github.com wrote:
I found tthe problem. src is listed in osv-apps/.gitingore. so the whole directory is ignored by git.
I will make another pull request to fix this.
— Reply to this email directly or view it on GitHub https://github.com/cloudius-systems/osv-apps/pull/23#issuecomment-98641377 .
Nadav Har'El nyh@cloudius-systems.com
@nyh
I'm not sure this is a viable approach in the long run (will you have to do this for many ports?)
There are only four ports, cpu_sup, memsup, disksup and inet_gethost (there is no disksup actually, erlang just uses df
). inet_gethost could be disabled by configuration. cpu_sup requires /proc/stat, I didn't find anything close to it in OSv.
memsup and disksup spawn external process to collect data. Now, they have been rewritten as port drivers.
Signed-off-by: bhuztez bhuztez@gmail.com
try in Erlang Shell