On 1/16/19 8:14 AM, Jens Axboe wrote:
> On 1/16/19 3:53 AM, Arnd Bergmann wrote:
>> On Tue, Jan 15, 2019 at 3:56 AM Jens Axboe <[email protected]> wrote:
>>
>>> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
>>> index 542757a4c898..e36c264d74e8 100644
>>> --- a/include/linux/syscalls.h
>>> +++ b/include/linux/syscalls.h
>>> @@ -314,6 +314,8 @@ asmlinkage long sys_io_uring_setup(u32 entries,
>>>                                 struct io_uring_params __user *p);
>>>  asmlinkage long sys_io_uring_enter(unsigned int fd, u32 to_submit,
>>>                                 u32 min_complete, u32 flags);
>>> +asmlinkage long sys_io_uring_register(unsigned int fd, unsigned op,
>>> +                               void __user *arg);
>>>
>>
>> Would it be possible to make this a typed pointer instead? If this needs to
>> be extended later to pass a different structure, a new system call may
>> be better for consistency than overloading the argument in various
>> ways.
> 
> As you can see from the later patch for registering files, it'll be used
> for other structs too. Feels a little silly to add an extra system call
> for that. I agree the void * isn't the prettiest thing in the world, but
> at least it allows us to extend the API without having to add even more
> system calls down the line.

With the __u64 changes, we end up with this:

struct io_uring_register_buffers {
        __u64 iovecs;           /* pointer to iovecs array */
        __u32 nr_iovecs;        /* number of iovecs in array */
        __u32 pad;
};

struct io_uring_register_files {
        __u64 fds;
        __u32 nr_fds;
        __u32 pad;
};

which are identical. So the question then becomes if I should just make
these opaque enough to be the same thing, ala:

struct io_uring_register_data {
        __u64 data;
        __u32 nr_elems;
        __u32 pad;
};

and then probably add a bit more reserved space so we have something
that can be extended...

-- 
Jens Axboe

Reply via email to