We use generated Rust bindings to libubus, and our own thread as opposed to uloop. "container_of", quite aside from not being exported, violates the strong types and memory safety rules we've previously been able to uphold. This isn't an issue with callbacks from "ubus_invoke_fd", where we can pass a pointer to some private (repr(C), for those who care) type in "priv" and pick up context from that.
Since we don't have direct access to C macros at all, container_of is far from ideal. This is the first instance where it has been required. Do C++ libubus users make use of "container_of"? ~ Louis Felix Fietkau writes: > On 2021-07-13 13:57, [email protected] wrote: >> >> This is particularly useful in multithreaded non-C FFI, where >> additional context from where the event handler was registered may be >> critical to ensuring the output of the event is sent to the right >> location. >> >> Signed-off-by: Louis Hampton <[email protected]> > In order to get the additional context, the normal solution is to embed > struct ubus_event_handler into another data structure, which contains > the extra context and can be accessed via container_of. > Is there a reason why this can't be done in your code as well? > > - Felix _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
