shared dataspace for l4re_kernel/ registering additional caps in ned

[Björn Döbel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> for a project, I want to be able to load (elf-)binaries not only
> from the filesystem, but also from the network (receive binary,
> then start it.) For this, I will write a L4 app (let's call it
> "manager" for now) which handles the network part and then tells
> ned to start the received binary via a special "filename". I
> already modified ned so that its LUA-interface is exposed to other
> apps via a capability.

How about this: L4Re provides a virtual file system that you can use
to implement your own file systems. Your manager could thereby provide
access to networked files through a network file system and would
"only" have to implement the Vfs interface for that.

There is an example for a locally implemented temp FS in l4/pkg/tmpfs.
In your case your client-local library would call the external manager
service, which would then provide file access.

Now your next problem will be to make this new FS known to Ned...

> But here comes the first problem: Normally you specify the
> capability table of a task and an IPC channel in the lua-config
> file, which ned reads. Ned then prepares the channel and the caps
> table and starts the task, which then can register the capability.
> Otherwise, registering fails (the example would do a printf("Could
> not register my service, is there a 'calc_server' in the caps
> table?\n");) So... how do I specify which capabilities ned itself
> can have/register? Currently, I need to have a lua-config which
> tells ned to start another instance of ned with the required
> permission to register the capability. But is there any way to
> avoid having two ned instances and making the first (and only)
> instance able to register the cap?

Starting a second instance of ned to do that is a reasonable approach.

If you chose the Vfs option, you still need that, because you want to
launch your Manager with the initial Ned instance and only the second
Ned instance will then be able to access a file system provided by the
Manager (that's a bootstrapping problem here).

To tell the second Ned about your new FS, you will have to link it
with libmount (l4/pkg/libc_backends/lib/mount) and provide an fstab
file during startup in the Lua config as this:

ldr:startv( { caps = {},
              log = { "myapp", "red" }
            },
            "rom/myapp",
            {
                FSTAB_FILE="rom/myfstab.fstab"
	    });

This lib will then mount the new file system locally into your
application (e.g., the second ned instance).

> Second problem: I found out, that ned (also moe) doesn't start the 
> desired app directly but instead starts the l4re binary (source 
> located in src/l4/pkg/l4re_kernel), passing it the filename of the 
> desired binary. l4re, once started, gets the dataspace of this
> file and then ultimately starts the app. For my purpose, I would
> modify l4re_kernel so that if it detects the special "filename"
> mentioned above, it does not read the file from the filesystem but
> loads the binary that the "manager" received over the network.

This might work, but sounds like a hacky solution. With the
alternative outlined above you would simply retain the original way of
launching programs through the l4re binary. The only difference will
be that in your Lua script you launch a binary not as "rom/myapp" but
as "net/myapp" and the Vfs will make sure that the respective file
requests are then routed to the correct file system implementation.

Does that help you?

Bjoern
- -- 
Dipl.-Inf. Bjoern Doebel    Mail:  doebel at tudos.org
TU Dresden, OS Chair        Phone: +49 351 463 38 799
Noethnitzer Str. 46         Fax:   +49 351 463 38 284
01187 Dresden, Germany      WWW:   http://www.tudos.org/~doebel
- --
"When the seagulls follow the trawler, it's because they think
 sardines will be thrown into the sea." (Eric Cantona)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlPrDkQACgkQP5ijxgQLUNlzuQCfY7H3Vzu0nsE78/ScxMDhgpIg
740Anilmv6fnDdmbkg38xBI+q0CHVKK5
=E9N9
-----END PGP SIGNATURE-----