On 1/26/2020 8:00 PM, Jens Axboe wrote:
> On 1/26/20 8:11 AM, Pavel Begunkov wrote:
>> On 1/26/2020 4:51 AM, Daurnimator wrote:
>>> On Fri, 24 Jan 2020 at 10:16, Jens Axboe <axboe@xxxxxxxxx> wrote:
>>>
>>> I don't love the idea of some new type of magic user<>kernel
>>> identifier. It would be nice if the id itself was e.g. a file
>>> descriptor
>>>
>>> What if when creating an io_uring you could pass in an existing
>>> io_uring file descriptor, and the new one would share the io-wq
>>> backend?
>>>
>> Good idea! It can solve potential problems with jails, isolation, etc in
>> the future.
>>
>> May we need having other shared resources and want fine-grained control
>> over them at some moment? It can prove helpful for the BPF plans.
>> E.g.
>>
>> io_uring_setup(share_io-wq=ring_fd1,
>> share_fds=ring_fd2,
>> share_ebpf=ring_fd3, ...);
>>
>> If so, it's better to have more flexible API. E.g. as follows or a
>> pointer to a struct with @size field.
>>
>> struct io_shared_resource {
>> int type;
>> int fd;
>> };
>>
>> struct io_uring_params {
>> ...
>> struct io_shared_resource shared[];
>> };
>>
>> params = {
>> ...
>> .shared = {{ATTACH_IO_WQ, fd1}, ..., SANTINEL_ENTRY};
>> };
>
> I'm fine with changing/extending the sharing API, please send a
> patch!
>
Ok. I can't promise it'll play handy for sharing. Though, you'll be out
of space in struct io_uring_params soon anyway.
--
Pavel Begunkov
