> Hopefully they shouldn't be
> much different from standard ethernet cards. 

SCI is a lot different model than Ethernet.  SCI is designed to provide memory 
semantics, so that remote nodes look like an additional address space.  You 
could probably layer sockets on top of it, but I think you will be better if 
you work on either porting a message passing API into RTEMS, and make the SCI 
hardware the underlying mechanism (you'll have to research which message 
passing API's seem to be in favor with the clustering community these days), 
or simply use the SCI hardware for a shared memory region in RTEMS.

Take a look at the dual-ported memory manager in the RTEMS application 
programming documentation, that looks like it might be a good fit.
If you are using PC386 BSP, you will probably have to change the BSP so that 
part of the system memory gets set up as normal RTEMS heap memory, and part is 
reserved as SCI accessible memory.  The SCI cards will have to be configured 
to allow remote access to the SCI memory.
At each node, there will have to be some mechanism to allow RTEMS to know that 
a shared (i.e. dual ported) memory region is available, probably compile time 
is the easiest assuming you can set up the hardware so that it is all 
identical and doesn't change.
For N nodes, each node would have N dual ported memory regions defined, with 
one accessible using internal addresses (the local shared memory on that 
node), and N-1 using external addresses (accessed through the SCI card).

You would only need to mess with the multi-processor support in RTEMS if you 
want RTEMS objects to be shared between the nodes.  If you can get away with 
not sharing any RTEMS objects, and have only application data in the shared 
memory, I think you can use just the dual port memory manager.

You could of course create a Multi-Processor Communications Interface (see 
section 23.3 in the RTEMS 4.5.0 application documentation), it just depends on 
what you are trying to do.  Maybe both, start out with working on a dual 
ported memory implementation, then when that is working you could work on 
adding a message passing interface which uses the dual ported memory.

-- Chris Caudle



