Distributed Erlang on GRiSP

[grisp]

Distributed Erlang on GRiSP

[c-mauderer]

Maybe an odd question but: What is a cookie file? Is that something that is necessary for Erlang? Where would it be located?

In the default case, the SD card is mounted at /media/mmcsd-0-0. So if you create a "home" on it, it might have another location than you would expect.

Please also note that RTEMS has only a very limited concept of users. I wouldn't be sure whether permissions are fully implemented for an IMFS.

[ThomasArts]

Indeed, this cookie is Erlang specific, but file permission issue is general. That is why I wrote it here.

When Erlang starts in distributed mode, it needs a "cookie", which basically is a plain text password that allows to talk to that node. If no such cookie exists, the Erlang statup process creates one.
For good or bad reasons, the permissions of the file are checked by Erlang during startup. And if it is not a cookie that only the user starting the Erlang VM can read, the Erlang startup is aborted.

[c-mauderer]

Hm. I think I don't can come up with a good and easy solution for that.

@peerst: I think the former port used another file system where that problem didn't exist, right?

I could think of two workarounds:

1. Create a second partition on the SD card and format it with the RTEMS file system (rfs). Disadvantage: As far as I can tell, that file system isn't readable by a PC.

2. Use an IMFS. I would suggest that solution. There is a function for loading a IMFS from a tar file in RTEMS:
   https://github.com/grisp/rtems/blob/3e7827434d3/cpukit/libfs/src/imfs/imfs.h#L481
   Example: https://github.com/grisp/rtems/blob/3e7827434d3/testsuites/libtests/tar02/init.c#L106
   Basically you have to read a tar file into memory and then use rtems_tarfs_load on a pointer to that memory region.

[peerst]

To 1: Well if rfs is any good we could move fully towards it

To 2: Yeah that would be one possibility to either copy the file or use rtems_tarfs_load

Other possibilities:

a.) Add a option to Erlang to ignore the access rights

-> that would help others stuck on a FAT filesystem

b.) Store the cookie not in a filesystem at all, we could also put it in EEPROM e.g. or have a fake filesystem that gets it from EEPROM

Since its a clear text file anyway the workaround of putting it in the command-line is also not so bad