[Barrelfish-users] Porting Barrelfish to a new architecture?

[Matt Johnson]

Hi All,
     My research group develops a simulator, compiler toolchain, 
libraries, and apps for
investigating many-core architectures.  We recently released a large 
portion of our
infrastructure ( http://rigelproject.github.com ) and are looking for 
contributors.
One part of that is making a list of worthwhile projects for outside 
contributors
to work on.  In the interest of expediency, our architecture definition 
and simulator
so far are more like a GPU than a CPU in that they do not support many 
of the constructs
needed for a multitasking operating system (interrupts, inter-processor
interrupts, timers, traps, MMU, etc.).

     We would like to flesh out the architecture and simulator to 
efficiently support
an operating system.  At a high level, Barrelfish seems like a great 
design driver
for our OS support mechanisms, since it is explicitly designed for 
many-core and
heterogeneous systems.  My questions are:

* What primitives does Barrelfish *require* of the underlying CPU 
(atomic instructions,
   interrupts, MMU features, etc.)?
* What additional primitives, if any, are desirable for existing versions of
   Barrelfish to run well?
* What further primitives would Barrelfish developers like to see on 
future hardware
   platforms?
* How would one go about porting Barrelfish to another architecture?
   - Is CPU support code segregated into one part of the Barrelfish 
source tree?
     If not, what general patterns should I grep for?
     I see things like .dev files for amd64 and arm, but don't know what 
else is required.
* This is likely a dumb question, but does my architecture need ghc 
codegen support
   to run Barrelfish?  If so, we have an LLVM backend, but I don't know 
to what extent
   that counts as ghc codegen support.
* At a high level, is this worth doing?  There are two parts to that:
   - If the port is successful, is there any hope of upstreaming the 
changes so
     they can keep pace with upstream API changes?  (Remembering that 
the platform
     in question consists of a simulator, and possibly an FPGA in the 
foreseeable future)
   - If not, is the upstream API or organization likely to change in 
such a way that the
     port will quickly become non-functional?
   - Would it be a Herculean effort, or something a student or two could 
do in O(weeks)?

If any or all of this is covered by a doc somewhere, don't hesitate to 
point me to
it in lieu of a long response.  If it's not, I hope this thread can 
serve as the
beginnings of such a document.

Best,
Matt