[LEDE-DEV] [PATCH] Allow sending a fd in a ubus_request

[Felix Fietkau]

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