[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.
Thanks,
Todd Templeton
UC Berkeley
Details, for those who are interested:
The NetBurner systems are vaguely POSIX-like, with a few crucial
differences:
- 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
configure)
- 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
systems
- 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
initialization.
- 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