Re: shared dataspace for l4re_kernel/ registering additional caps in ned
>>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).
>
>Ned doesn't need to know about this filesystem,
>but my manager application and the l4re thread of
>the new task do.
>
>Linking and using the manager with libmount works fine.
>
>But I have some problems linking l4re with libmount.
>Mostly undefined references:
>
>Initially, I tried simply adding libmount to REQUIRES_LIBS
>of the makefile, but that gave a lot of linker errors.
>So I replaced most of the minimal lib versions with the full-
>fledged ones:
>REQUIRES_LIBS := libc l4re-util libstdc++ libloader \
>cxx_libc_io libc_be_minimal_log_io
>
>Without libmount, this also builds fine.
>But after adding libmount, this leads to undefined references of
>open, fstat, mount and close.
>After adding libc_be_l4refile to the list (since it seems to contain the
>missing symbols), l4re_env_posix_vfs_ops is undefined.
>And since this is AFAIK only found in libl4re-vfs, I tried adding it,
>but then the build stops with this error:
>"src/l4/mk/binary.inc:335: *** Never include 'libl4re-vfs'!. Stop."
Ok, so I worked around this error message by removing the sanity
check from src/l4/mk/binary.inc; l4re then gets linked with libmount.
I then also linked libl4revfs-fs-l4fs successfully to l4re.
However, whenever I supply a fstab-file to a new task
(via FSTAB_FILE=...), mounting with libmount still fails,
and the target task then even stops without executing main().
Error displayed:
" test | mmap() called without MAP_ANON flag, not supported!
test| libmount: Parsing 'rom/fstab'
MOE[rm]: unhandled read page fault at 0x0 pc=0xb000eeb4"
Anyway, then I tried to let l4re mount the filesystem without
libmount, by inserting mount("none","/tmp","l4fs",0,0);
just after the line
boot.printf("load binary '%s'\n", Global::l4re_aux->binary);.
However, the mount fails; a perror("mount") after simply
yields "mount: Invalid argument". The same mount
command however works fine in conventional threads.
(Note that a l4fs/libfs-server is running and the needed
IPC-Gate has been given to the task. "Normal" tasks/
threads can actually use this server.)
Any ideas how I could convince l4re (l4re_kernel) to
mount a libfs/l4fs-type FS?
Thanks in advance,
Josef
P.S.: If you view this mail via the mailinglist-archive,
the first half of this thread can be found in 2014,
since it began there.
___
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
Hey, I am currently working on this:
>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).
Ned doesn't need to know about this filesystem,
but my manager application and the l4re thread of
the new task do.
Linking and using the manager with libmount works fine.
But I have some problems linking l4re with libmount.
Mostly undefined references:
Initially, I tried simply adding libmount to REQUIRES_LIBS
of the makefile, but that gave a lot of linker errors.
So I replaced most of the minimal lib versions with the full-
fledged ones:
REQUIRES_LIBS := libc l4re-util libstdc++ libloader \
cxx_libc_io libc_be_minimal_log_io
Without libmount, this also builds fine.
But after adding libmount, this leads to undefined references of
open, fstat, mount and close.
After adding libc_be_l4refile to the list (since it seems to contain the
missing symbols), l4re_env_posix_vfs_ops is undefined.
And since this is AFAIK only found in libl4re-vfs, I tried adding it,
but then the build stops with this error:
"src/l4/mk/binary.inc:335: *** Never include 'libl4re-vfs'!. Stop."
So, how can I link l4re (found in pkg/l4re_kernel) successfully with libmount?
Thanks,
Josef
___
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
On Sat Sep 20, 2014 at 20:45:19 +, Stark, Josef wrote:
> Everything's working so far! But I have another question... (the actual
> question is at the bottom)
>
> Here's what I do now:
> If manager wants to start a received binary, it tells Ned to start "network",
> e.g. start({caps = {ipc_gate= L4.Env.ipc_gate}},"network"); and Ned then
> starts
> - as usual - l4re. l4re then detects the special filename - "network" - and
> instead of
> trying to load a file with this filename from ROM (which doesn't exist) it
> asks manager for
> the shared dataspace which holds the binary. Since manager may alter the
> content
> of the shared dataspace later, l4re copies the shared dataspace and then
> launches this copy.
>
> So, basically, (in main.cc of l4re_kernel) instead of
>
> file = L4Re_app_model::open_file(Global::l4re_aux->binary);
>
> we do
>
> L4::Cap ds;
> get_shared_dataspace(ds); //allocation and IPC stuff
> file=L4Re_app_model::alloc_ds(ds->size()); //this method is now static
> L4Re_app_model::copy_ds(file,0,ds,0,ds->size());
>
> and then continue with the regular
>
> loader.start(file, Global::local_rm, Global::l4re_aux);
>
> which works.
>
>
> But my question is, once the task gets killed or finishes, do I need to
> release/free/unmap
> the dataspace "file" again (since it is a copy in memory and not a file on
> ROM)
> to avoid a resource leak, and, if so, where whould I do this? Or is this done
> automatically?
This will be done automatically. Moe will free resources when all
clients are gone.
Adam
--
Adam [email protected]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
___
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
Everything's working so far! But I have another question... (the actual
question is at the bottom)
Here's what I do now:
If manager wants to start a received binary, it tells Ned to start "network",
e.g. start({caps = {ipc_gate= L4.Env.ipc_gate}},"network"); and Ned then starts
- as usual - l4re. l4re then detects the special filename - "network" - and
instead of
trying to load a file with this filename from ROM (which doesn't exist) it asks
manager for
the shared dataspace which holds the binary. Since manager may alter the content
of the shared dataspace later, l4re copies the shared dataspace and then
launches this copy.
So, basically, (in main.cc of l4re_kernel) instead of
file = L4Re_app_model::open_file(Global::l4re_aux->binary);
we do
L4::Cap ds;
get_shared_dataspace(ds); //allocation and IPC stuff
file=L4Re_app_model::alloc_ds(ds->size()); //this method is now static
L4Re_app_model::copy_ds(file,0,ds,0,ds->size());
and then continue with the regular
loader.start(file, Global::local_rm, Global::l4re_aux);
which works.
But my question is, once the task gets killed or finishes, do I need to
release/free/unmap
the dataspace "file" again (since it is a copy in memory and not a file on ROM)
to avoid a resource leak, and, if so, where whould I do this? Or is this done
automatically?
Thanks
Josef
___
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
Hello Adam,
>If I understand correctly, I think you need to write
>caps = { ipc_gate = L4.Env.ipc_gate }
>
>L4.Env.ipc_gate is the cap given to the second ned by the first one, so
>it's in its environment.
thank you SO much, this works!
Josef
___
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
Hi,
On Fri Sep 12, 2014 at 11:06:04 +, Stark, Josef wrote:
> I've succeeded a bit since my original question, however it seems that I'm
> stuck at the same or a related problem I mentioned there.
> I have not found a solution so far.
> I'll try to explain it as short as possible:
>
> In my lua config file, I create an IPC gate, and then launch my manager and a
> second ned instance, passing the IPC gate to both.
> So now manager can send LUA commands through the IPC gate, which then ned
> executes. This works so far.
>
> But I also want newly (through manager and second ned) created tasks (or its
> l4re thread) to be able to talk to manager.
> For this, I created a second IPC gate in the config and also passed it to
> manager and ned. Let's call it ipc_gate.
> If, however, manager then issues e.g. the following LUA call (which creates
> the new task and passes the IPC-gate capability),
> the new task is still not able to communicate with manager.
> "hello = L4.default_loader:start( { caps = { ipc_gate = ipc_gate } },
> "rom/hello");
> I guess it's because it's another layer and second ned doesn't "know" about
> the IPC gate which is created
> in the config file and thereby by first ned, even if I pass the capability to
> him.
>
> So, is there any way to enable IPC communication between manager and new
> tasks created by the second ned?
If I understand correctly, I think you need to write
caps = { ipc_gate = L4.Env.ipc_gate }
L4.Env.ipc_gate is the cap given to the second ned by the first one, so
it's in its environment.
> I tried to illustrate it by making a small diagram (it the font messes it up,
> I've also attached a png image of it).
> What I need is the ipc line between manager and hello to work.
Thanks, that helped!
Adam
--
Adam [email protected]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
___
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
Hello again,
I've succeeded a bit since my original question, however it seems that I'm
stuck at the same or a related problem I mentioned there.
I have not found a solution so far.
I'll try to explain it as short as possible:
In my lua config file, I create an IPC gate, and then launch my manager and a
second ned instance, passing the IPC gate to both.
So now manager can send LUA commands through the IPC gate, which then ned
executes. This works so far.
But I also want newly (through manager and second ned) created tasks (or its
l4re thread) to be able to talk to manager.
For this, I created a second IPC gate in the config and also passed it to
manager and ned. Let's call it ipc_gate.
If, however, manager then issues e.g. the following LUA call (which creates the
new task and passes the IPC-gate capability),
the new task is still not able to communicate with manager.
"hello = L4.default_loader:start( { caps = { ipc_gate = ipc_gate } },
"rom/hello");
I guess it's because it's another layer and second ned doesn't "know" about the
IPC gate which is created
in the config file and thereby by first ned, even if I pass the capability to
him.
So, is there any way to enable IPC communication between manager and new tasks
created by the second ned?
I tried to illustrate it by making a small diagram (it the font messes it up,
I've also attached a png image of it).
What I need is the ipc line between manager and hello to work.
moe
|
| (starts)
|
v
--
ned
|
| (executes and starts)
|
v
config(lua)---
manager <--->ned
^ (ipc) |
\|
(ipc) \ | (starts)
\ |
\ |
---\|-
v v
hello
Thanks in advance!
Josef___
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Out of curiosity: What exactly does l4re do, or why doesn't ned > start new tasks directly? l4re implements the Region Manager -- this is a thread running inside your application's address space and handling the page faults raised by all other threads. Bjoern -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlPzSZQACgkQP5ijxgQLUNn5awCaAtEYw509S6h3Ws54xvATMSBq umgAoIaJm5Y90Xe89AIn15mmWUSOwC+6 =w/fQ -END PGP SIGNATURE- ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
>> in case anyone else is interested, here's what I found out so far: >> So, as mentioned earlier, if ned wants to launch a certain task you >> specified, >> ned does so indirectly by launching l4re and passing the name of the target >> binary to l4re, >> so l4re is basically the "parent" of the target task. > >Parent maybe but not in the sense of a task because l4re runs in the >very same task as the application. > >> As a parent, it seems that it receives all the capabilities you >> specified in your lua config >> for the target task, so doing IPC between l4re and _another_ task >> seems much easier than expected. > >It's just because they share the same task. That's actually good to know! Out of curiosity: What exactly does l4re do, or why doesn't ned start new tasks directly? Josef ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
Some comments only. On Sun Aug 17, 2014 at 11:03:07 +, Stark, Josef wrote: > in case anyone else is interested, here's what I found out so far: > So, as mentioned earlier, if ned wants to launch a certain task you specified, > ned does so indirectly by launching l4re and passing the name of the target > binary to l4re, > so l4re is basically the "parent" of the target task. Parent maybe but not in the sense of a task because l4re runs in the very same task as the application. > As a parent, it seems that it receives all the capabilities you > specified in your lua config > for the target task, so doing IPC between l4re and _another_ task > seems much easier than expected. It's just because they share the same task. > I could successfully share a dataspace between a third task and l4re. > I used the config file from the shared_ds example, changed the client > sourcecode so that it only printed a "Hello" and then slept forever. > The part where it accesses the dataspace from the server was moved > (the part where it changes the ds content again was left out since I > did not need it) into l4re_kernel (the l4re binary), but is only > triggered if the name of the target binary was "ds_clnt", so that this > code wasn't executed multiple times (I know, this is _very_ hacky, but > remember, it should only serve as an example). > > And indeed, now l4re itself was able to print the content of the > dataspace. > (Accessing the ds from both l4re and its child also works, although > this wasn't my intention and I don't need it.) Ok, good but no suprise either :) > Instead of sharing a dataspace it should also be possible to do normal > IPC calls between l4re and a third task, e.g. to implement a central > temporary filesystem (which then can also be accessed from within > l4re) like mentioned in a previous mail. Yes. Basically, as you found out, with shared memory any thread/task that has access to this memory can access it and exchange data. Adam -- Adam [email protected] Lackorzynski http://os.inf.tu-dresden.de/~adam/ ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
-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 DoebelMail: [email protected]
TU Dresden, OS ChairPhone: +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-
___
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
