5 ms·

I don't think I'd agree that Nerves is "firmware". Nerves is, at its root, buildroot linux and Erlang, with an Erlang "init". At least the last time I looked, t

I don't think I'd agree that Nerves is "firmware". Nerves is, at its root, buildroot linux and Erlang, with an Erlang "init". At least the last time I looked, the "hardware interface" was just file I/O operations in sysfs. Which is cool and all, but that's just a process in Linux userland reading and writing files. I spent quite some time trying to get tighter integration between a kernel module and the Erlang runtime. Because of the way Erlang works, one can't select(2)/poll(2) file descriptors in a useful way, which makes sysfs interrupt files less useful. I wrote a very simple Erlang node[0] to send messages when select/poll returns. It works okay, but the jitter is very high. Peer Strizinger wrote something called Grisp[1] which uses the POSIX interface to RTEMS[2] to run Erlang without a canonical OS. RTEMS is still ultimately an embedded kernel, but it keeps you much closer to the metal than Linux. Unfortunately, Peer hasn't/won't release his code despite my pleas. Most promisingly, there's Cloudozer's Erlang on Xen port to the Raspberry Pi[3]. This is a clean-sheet Erlang VM implementation that actually runs bare-metal (no POSIX!). The code is definitely experimental and I don't have the time to try to retarget it to my preferred platforms, but it's exciting anyway. It's definitely what I would call "firmware" in Erlang. Anyway, Nerves is cool, but it's (u-boot + Linux + epmd + BEAM). [0] https://github.com/thenewwazoo/erl_poc/blob/master/c_src/node.c https://github.com/thenewwazoo/erl_poc/blob/master/c_src/nod... [1] http://www.grisp.org http://www.grisp.org [2] http://www.rtems.org http://www.rtems.org [3] https://github.com/cloudozer/ling/tree/raspberry-pi https://github.com/cloudozer/ling/tree/raspberry-pi

wyager 10y ago
If you have many erlang actors waiting on IO, does the runtime automatically epoll all those file descriptors? Most things in Haskell work this way. If you wanted to get epoll behaviour without actually calling epoll yourself, you could spawn a ton of processes to wait on different sockets or whatever and then just have them write into an STM container when they receive anything. The thread receiving from x million different clients or whatever just keeps reading from the STM container. Of course, at large scale you would probably just use epoll directly and save on the few hundred bytes per thread overhead.
- thenewwazoo 10y ago
  It's been a while now and I don't remember the details, sorry. To the best of my recollection, the BEAM VM won't do a blocking select(2). Or maybe it forces use of poll(2) when cross-compiling? Basically, the gist is that it breaks the BEAM scheduler to block on I/O for longer than a very short time, and the file read code is pretty deeply internal, so you just can't do it (network sockets are a very special exception). You can poll a file (that is, repeated reads), but you can't block and wait for, e.g. sysfs_notify. Since all Erlang threads are green threads, there's no way to accomplish a blocking read within the auspices of the VM. Thus, the C node. My goal was to reduce the time between (physical) interrupt and Erlang thread response because I was trying to make sure I didn't miss an event.
jacobush 10y ago
That was the most interesting tech thing I saw for ... months at least. Thank you sir for your shared pointers and insight.
- thenewwazoo 10y ago
  Thanks! Now if only I could parlay my enthusiasm for embedded systems into related employment. :)
  - jacobush 10y ago
    Ditto...
dang 10y ago
> I don't think I'd agree that Nerves is "firmware". Nerves is, at its root, buildroot linux and Erlang, with an Erlang "init". Ok, we'll use that as a provisional title, since people here have been objecting to all the previous titles. If anyone can suggest a better (i.e. more accurate and neutral) one, we'll change it again. (Normally it isn't so hard to look at a project page and find a suitable description, but I couldn't do that here—this one is surprisingly on the other side of the breathless marketing divide. Et tu, Erlang?)
- gleb 10y ago
  The web page's original title is perfectly good. The new one is like an early investor is seeing AirBnb early on and saying "Oh, it's just like VRBO but with higher fees." True but not helpful, and not likely to result in a correct investment decision. * it's Elixir not Erlang * to the people who would use the project, it is "firmware" Nerves is really cool. And the cool part is that it's becoming possible to do what firmware programmers used to, but using higher level more productive languages/OS.
masklinn 10y ago
> The code is definitely experimental For Ling in general or for the raspi port?
- thenewwazoo 10y ago
  I meant for the port, but I'll admit that it's supposition on my part. It doesn't look like the Rπ port keeps feature/fix parity with the main branch, but I may be mistaken.
abrookewood 10y ago
Ling appears to be abandoned though ... no activity in the repo for a year, no website updates etc.

wyager 10y ago

If you have many erlang actors waiting on IO, does the runtime automatically epoll all those file descriptors? Most things in Haskell work this way. If you wanted to get epoll behaviour without actually calling epoll yourself, you could spawn a ton of processes to wait on different sockets or whatever and then just have them write into an STM container when they receive anything. The thread receiving from x million different clients or whatever just keeps reading from the STM container. Of course, at large scale you would probably just use epoll directly and save on the few hundred bytes per thread overhead.

thenewwazoo 10y ago
It's been a while now and I don't remember the details, sorry. To the best of my recollection, the BEAM VM won't do a blocking select(2). Or maybe it forces use of poll(2) when cross-compiling? Basically, the gist is that it breaks the BEAM scheduler to block on I/O for longer than a very short time, and the file read code is pretty deeply internal, so you just can't do it (network sockets are a very special exception). You can poll a file (that is, repeated reads), but you can't block and wait for, e.g. sysfs_notify. Since all Erlang threads are green threads, there's no way to accomplish a blocking read within the auspices of the VM. Thus, the C node. My goal was to reduce the time between (physical) interrupt and Erlang thread response because I was trying to make sure I didn't miss an event.

jacobush 10y ago

That was the most interesting tech thing I saw for ... months at least. Thank you sir for your shared pointers and insight.

thenewwazoo 10y ago
Thanks! Now if only I could parlay my enthusiasm for embedded systems into related employment. :)
- jacobush 10y ago
  Ditto...

dang 10y ago

> I don't think I'd agree that Nerves is "firmware". Nerves is, at its root, buildroot linux and Erlang, with an Erlang "init". Ok, we'll use that as a provisional title, since people here have been objecting to all the previous titles. If anyone can suggest a better (i.e. more accurate and neutral) one, we'll change it again. (Normally it isn't so hard to look at a project page and find a suitable description, but I couldn't do that here—this one is surprisingly on the other side of the breathless marketing divide. Et tu, Erlang?)

gleb 10y ago
The web page's original title is perfectly good. The new one is like an early investor is seeing AirBnb early on and saying "Oh, it's just like VRBO but with higher fees." True but not helpful, and not likely to result in a correct investment decision. * it's Elixir not Erlang * to the people who would use the project, it is "firmware" Nerves is really cool. And the cool part is that it's becoming possible to do what firmware programmers used to, but using higher level more productive languages/OS.

masklinn 10y ago

> The code is definitely experimental For Ling in general or for the raspi port?

thenewwazoo 10y ago
I meant for the port, but I'll admit that it's supposition on my part. It doesn't look like the Rπ port keeps feature/fix parity with the main branch, but I may be mistaken.

abrookewood 10y ago

Ling appears to be abandoned though ... no activity in the repo for a year, no website updates etc.