I think you need another pointer layer for variables. So:
#[linkage = "extern_weak"]
static camkes_buffer: *const*mut u8;
And then another dereference when you assign to it.
I don't know if this is a bug in rust - there is an example of it in a comment
on the rust issue I linked in my last email.
Kent.
________________________________________
From: Michal Podhradsky [[email protected]]
Sent: Friday, August 18, 2017 8:33 AM
To: Mcleod, Kent (Data61, Kensington NSW)
Cc: [email protected]
Subject: Re: [seL4] rumprun + rust + camkes
Hello Kent,
thanks for your reply. The functions pointers definitely are not prettiest, but
if needed a nicer wrapper function or a macro can be added in the rust app.
However, I tried adding a shared buffer (dataport) in the rust app, to emulate
the reverse string functionality from the rump_ethernet app.
I add a static pointer to a C array:
#[linkage = "extern_weak"]
static camkes_buffer: *mut u8;
and then modify the buffer before sending camkes_ev_emit():
*camkes_buffer.offset(0) = 'a' as u8;
...
But when I run the application, I get this result:
=== calling "hello" main() ===
Hello rust!
Server: Got string:
Server: Buffer[0]=0
Waiting for event!
Got event!
RUST: Buffer: 97
=== main() of "hello" returned 0 ===
Which looks like the memory is not shared, although the connection is
established and the interface is exposed.
The changes are summarized here:
https://github.com/GaloisInc/camkes/commit/6dd2873fbd58133b798e359cb0ff5f5d62712816
Is there something I am missing?
Regards
Michal
On Thu, Aug 17, 2017 at 6:18 AM,
<[email protected]<mailto:[email protected]>> wrote:
Hello Michal,
I haven't found a nice way of linking CAmkES generated symbols against the top
level of rumprun apps yet. By top level I mean the POSIX app that gets linked
against syscall layer, and the bottom level is the implementation of the
syscall layer including the rump kernel, platform layer code, and camkes
generated code. The two layers are individually compiled and linked separately
and both have a main function. When the layers are combined into the same
address space, the main function in the top layer is renamed and it is then
linked with the bottom layer (this is done using the rumprun_bake tool).
Symbols are effectively name-spaced so that they don't collide across the two
layers.
The CAmkES generated connectors are compiled and linked into the bottom layer.
I don't think it is currently possible to take the generated objects, create a
new archive of them and then link the archive into the top layer without ending
up with two sets of the same symbols. Maybe there needs to be a way to mark
connections as either top level or bottom level and they will only be linked in
once (this would also nicely extend to supporting connectors that directly
generate rust instead of C).
The current way I achieve what you want in the Ethernet app is by marking the
symbols weak in the top layer, the compiler won't complain if they don't
exist, and then when the top is combined with the bottom, the symbols are
successfully linked.
I managed to get this working with your rust app here:
https://github.com/kent-mcleod/camkes/tree/rustapp
It isn't pretty, and I hope there is a better way in Rust of marking C foreign
functions as weak. See this discussion here for more info:
https://github.com/rust-lang/rust/issues/29603
Rust only allows pointers to be marked as weak which is why the functions in
the rust code are declared as function pointers, and then cast to actual
functions (yuck).
Kind regards,
Kent
________________________________
From: Devel <[email protected]> on behalf of Michal Podhradsky
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, August 16, 2017 5:04 AM
To: [email protected]
Subject: [seL4] rumprun + rust + camkes
Hello Kent,
I extended the rumprun+rust example (available in this
PR<https://github.com/seL4/camkes/pull/4>) with a simple camkes connection
between the rumprum camkes component and a serial server component, as shown
below (full code
here<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_rust/rumprun_rust.camkes>):
composition {
component rumprun_platform_layer rrpl;
component rumprun_rust hello1;
RUMPRUN_META_CONNECTION(hello1, rrpl)
component rumprun hello2;
RUMPRUN_META_CONNECTION(hello2, rrpl)
component Server server;
connection seL4SharedData conn(from hello1.camkes_buffer, to
server.buffer);
connection seL4Notification simpleEvent1(from hello1.camkes_ev, to
server.ev);
connection seL4Notification simpleEvent2(from server.ev1, to
hello1.camkes_ev1);
}
I added a simple rust
program<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_rust/components/hellorust/rustest/src/main.rs>
(running on rumprun_rust):
fn main() {
println!("Hello rust!");
unsafe {
camkes_ev_emit();
}
println!("Waiting for event!");
unsafe {
camkes_ev1_wait();
}
println!("Got event!");
}
#[no_mangle]
extern {
fn camkes_ev_emit();
fn camkes_ev1_wait();
}
In order to compile the cargo project, I added a build.rs
script<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_rust/components/hellorust/rustest/build.rs>
to package the generated camkes object file (camkes.o) into an archite that
cargo can link against.
The problem is, that the generated camkes.c file contains its own main function:
int USED main(int argc UNUSED, char *argv[]) {
assert(argc == 2);
assert(strcmp(argv[0], "camkes") == 0);
int thread_id = (int)(uintptr_t)(argv[1]);
return post_main(thread_id);
}
which collides with the fn main() defined in rust. (I get multiple definition
of `main' error).
How is this handled in
rumprun_ethernet<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_ethernet/rumprun_ethernet.camkes>
example? There is also a main function for the rumpkernel
component<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_ethernet/components/rump_ether/tcp_server.c#L49>,
and the main() from camkes, but the compilation process handles this correctly.
Could you point me in the right direction?
Regards
Michal
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel
