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

[Baumann Andrew]

Hi Matt,

I've just been skimming over the Rigel and Cohesion papers -- interesting stuff!

To answer your questions:

> * What primitives does Barrelfish *require* of the underlying CPU 
> (atomic instructions,
>    interrupts, MMU features, etc.)?

We don't require atomic instructions. We do require some form of interrupts, for pre-emptive multitasking. We have run on a processor (Beehive) that lacked protection or address translation, but it was quite painful in many respects -- if you had some form of translation and a protected kernel mode, it would make a port much easier.

> * What additional primitives, if any, are desirable for existing versions of
>    Barrelfish to run well?

Efficient inter-core messaging would be great! (more on this below)

> * What further primitives would Barrelfish developers like to see on 
> future hardware
>   platforms?

Message-passing is the big one. We sketched out some ideas in this HotOS paper:
http://www.barrelfish.org/gap_hotos11.pdf

Essentially we'd like a remote write operation that pushes some data close to a remote core, and an asynchronous notification that causes a lightweight exception/control transfer on the target. Previous versions of hardware-supported message passing have provided some version of the former, but neglected the latter.

> * 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.

Our tree is not as cleanly structured as it should be, but in general architecture-specific code lives in a directory named 'arch', e.g. kernel/arch/x86_64, lib/barrelfish/arch/x86_64, etc. Aside from this, the main things you would need are suitable drivers, and the backends for message-passing.

> * This is likely a dumb question, but does my architecture need ghc 
> codegen support
>    to run Barrelfish?

No. GHC is used to build the tools, not the OS or apps. We definitely compile with GCC, and have at various times compiled with LLVM and ICC (so it shouldn't be hard to get these working if needed).

> * 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)

I can't give you a definitive answer (Mothy is perhaps better placed to do so), but there have been outside contributions to the tree. I think the main issue is one of maintenance bandwidth -- whether there are folks around who care about the port and are using/maintaining it. We recently removed the Beehive port from the tree, because it was unused, and we didn't have the cycles to keep it from bit-rotting.

>    - If not, is the upstream API or organization likely to change in 
> such a way that the
>      port will quickly become non-functional?

Well, it's a research project... and there is plenty of churn in the tree. Obviously with more ports and a better separation between architecture/platform-specific code this would be less of an issue, but we're not really at that state yet.

>    - Would it be a Herculean effort, or something a student or two could 
> do in O(weeks)?

It largely depends on how weird your platform is :) If it's not too strange, then I would say that a competent (i.e. knows how to debug C code running on the metal without a symbolic debugger) student could do it in a matter of weeks for the base system. Our early ports took more time, partly because they had to introduce some of the architectural separation that was missing.

If you're looking for reference code, the x86_64 port is the most complete, but the ARM port (done by Orion Hodson at MSR) is much cleaner.

Hope this helps,
Andrew