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]=0Waiting 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]> 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]> > *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
