[Barrelfish-users] binary execution in BF
kornilios.kourtis at inf.ethz.ch
Wed Apr 4 10:51:17 CEST 2012
Sorry for the delayed response. I'll try to give some pointers, but
please take my answers with a grain of salt. Other people might provide
more authoritative answers.
On Mon, Apr 02, 2012 at 08:53:11AM +0000, Georgios Varisteas wrote:
> I'm trying to track down the steps for loading a binary inside BF but
> most importantly creating a new process; reading the binary and setting
> up the environment like memory protection and all of that. Since I have
> no experience to guide me, I started from the upper level
> (execute_program() in fish or the newlib syscalls fork() and execve())
> and tried to follow the function calls to the kernel but got terribly
> lost. After hours of reading code I gave up and decided to email you.
> I would appreciate it greatly if you could point me to the specific
> files that handle:
> - process creation and management
Typical OS processes correspond to domains in barrelfish. Domains are
normally spawned by sending a message to the spawnd server. The
spawndserver setups everything and then performs the invoke_dispatcher()
system call to run the domain.
Some relevant files are:
- lib/barrelfish/spawn_client.c [client-side functions for interacting with spawnd]
- if/spawn.if [spawnd's interface]
- usr/spawnd/service.c [spawnd message handlers]
- lib/spawndomain/spawn.c [libary for spawning domains, used by spawnd]
- sys_dispatcher_setup() in kernel/syscall.c [arch generic part]
> - memory protection for either x86 or arm.
I would start with docs/TN-004-VirtualMemory.pdf, which introduces some
Some related source files are:
- lib/barrelfish/vspace/*.c for arch-independent files
- lib/barrelfish/vspace/arch/* for arch-specific files
If you are interested in arch-specific parts, looking at the
corresponding processor manuals might make it easier to understand what
the code does.
> Finally, I've picked up the stagnant task of porting BF to the Tile64
> arch. Again no previous experience in systems or OS, hence having a
> summarized "menu" of what must be done would go a long way. Apart from
> the obvious take all files in various "arch/" and "machine/" and
> rewrite them...
Another way to go is to try to do it incrementally -- i.e., starting with
trying to boot up the kernel single core and incrementally add
functionality. At some point the kernel should start the init service
which should spawn the monitor and other essential domains.
- kernel/arch/*/boot.S and kernel/arch/*/init.c (arch_init())
More information about the Barrelfish-users