On 2016-12-08 13:47, amine.ahd wrote: > In the current implementation, a fd can be sent in the reply to an existing > request which can be inefficient in certain cases. > Example: when you want to create a pipe between two process with the help of > a 3rd process acting as a manager: you need 3 pipe with the current > implementation and only one pipe with this patch. > > Basically the patch adds two new functions (ubus_invoke_fd and > ubus_invoke_async_fd) that are very similar to the original functions (open > to any other alternatives here) and a new msg type (UBUS_MSG_INVOKE_FD) to > copy the received fd to req_fd when processing the invocation. There's a lot of duplication in this patch. Please remove all the duplicate functions for starting requests, including UBUS_MSG_INVOKE_FD and all of its processing code.
There's a simpler way to deal with file descriptors: - Instead of adding ubus_start_request_fd, pass the file descriptor via struct ubus_request, preferably with a 'ubus_start_request_set_fd' helper function. - On the libubus receiver side, adjust all message process functions instead of having two different callback types, which gets a bit confusing. - Ensure that libubus always closes the file descriptor on the client side if the callback does not use it. Otherwise you create easily exploitable file descriptor leaks in all existing ubus services. Add a function ubus_request_get_caller_fd() which gets the caller's file descriptor and removes it from struct ubus_request_data. If a file descriptor is still in struct ubus_request_data after the callback, close it in libubus. This should make the patch shorter and more readable - Felix _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
