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