[Spread-users] Embedded Spread

Todd Templeton ttemplet at eecs.berkeley.edu
Mon Mar 17 18:23:26 EDT 2008

Hi all,

I would like to gauge interest in submitting back to the project minor 
changes to the Spread core that are required for ports of libspread-core 
to semi-POSIX-like embedded systems. In addition to writing some 
documentation about porting libspread-core to such systems, I would also 
be willing to submit a particular port as an example of how this can be 
done on the NetBurner platform--in addition to my interest in the 
platform, a quick web search shows that there was some interest in 
Spread on the NetBurner platform on this list last June. Right now I am 
working with the 4.0.0 release of Spread, but I would be happy to 
migrate my changes to the version in SVN.

One of the things that I like about Spread is the ability to run the 
application (compiled with libspread) on a separate machine from the 
heavy-weight multicast infrastructure (the Spread daemon). This is quite 
handy when using a mixture of normal and embedded computers--only 
libspread-core, and not the daemon, needs to be ported to, and run on, 
the embedded system.

Even if there is not enough interest in having the main Spread 
distribution support libspread-core for the NetBurner platform, I do 
think that it is valuable to have a consistent infrastructure for 
porting libspread-core to semi-POSIX-like embedded systems, since the 
Spread architecture is so amenable to this arrangement. The changes to 
the core of Spread that are required to make this happen are pretty 
minimal; I've listed general explanations of them at the end of the 
email, along with the fundamental differences in the software stack that 
make them necessary, for those who are interested.

Todd Templeton
UC Berkeley

Details, for those who are interested:

The NetBurner systems are vaguely POSIX-like, with a few crucial 
- although the compiler/linker is GNU, other parts of the build 
toolchain are nonstandard
- some standard functionality is contained in non-standard header files 
(and sometimes the standard header files exist, but are contradictory 
and cause the program to not compile)
- the sockets interface is simplified
- some setup needs to be done in main() (and, for normal usage, you 
write UserMain(), not main())

Minor changes required to core of Spread to make the port work:
- ARCH_PC_WIN95 is not sufficient to determine whether a system has UNIX 
domain sockets; I added ARCH_UNIX_DOMAIN_SOCKETS to specify whether the 
architecture supports UNIX domain sockets (configure automatically sets 
this when the system is not ARCH_PC_WIN95, but this port does not use 
- I gated the inclusion of several standard header files with the 
existing HAVE_x_H macros, but only inside #ifndef ARCH_PC_WIN95 (so that 
nothing has to change in the win32 build system)--note that config.h and 
defines.h are included if and only if ARCH_PC_WIN95 is not defined
- I added ARCH_EMULATED_SOCKETS, which includes emulatedsockets.h and 
bypasses the normal socket()/connect() connection scheme, instead 
requiring system-specific tcp_connect() and unix_connect() methods 
(which take timeout parameters). Any port can set this flag (it is never 
set automatically by configure), and write its own sockets emulation 
layer with header file emulatedsockets.h.
- I added the inclusion of basictypes.h if it exists--this seems like a 
good general way to allow definition of standard types on nonstandard 
- I split examples/user.c into user.c, user_impl.h, and user_impl.c. The 
file user.c now just includes user_impl.h, and has a one-line main() 
that calls user_impl.{c,h}'s main function (now called User_main()). 
This allows the port to reimplement user.c to do any required system 
- I added a netburner/ directory that contains its own makefile-based 
build system, a hand-tuned config.h, the emulatedsockets.* 
standard-sockets emulation layer, and an appropriate reimplementation of 
the new stripped-down examples/user.c

More information about the Spread-users mailing list