git: 022ca2fc7fe0 - main - Add aio_writev and aio_readv

[John Baldwin]

On 1/5/21 3:26 PM, Alan Somers wrote:
> On Tue, Jan 5, 2021 at 4:11 PM Brooks Davis <brooks at freebsd.org> wrote:
> 
>> On Sat, Jan 02, 2021 at 10:09:04PM -0700, Alan Somers wrote:
>>> On Sat, Jan 2, 2021 at 9:39 PM Jessica Clarke <jrtc27 at freebsd.org>
>> wrote:
>>>
>>>> On 3 Jan 2021, at 02:59, Alan Somers <asomers at FreeBSD.org> wrote:
>>>>> diff --git a/sys/kern/syscalls.master b/sys/kern/syscalls.master
>>>>> index b7ea5e939635..aaa0a1277461 100644
>>>>> --- a/sys/kern/syscalls.master
>>>>> +++ b/sys/kern/syscalls.master
>>>>> @@ -1477,7 +1477,17 @@
>>>>>                   _In_opt_ struct sigevent *sig
>>>>>               );
>>>>>       }
>>>>> -258-271      AUE_NULL        UNIMPL  nosys
>>>>> +258  AUE_AIO_WRITEV  STD {
>>>>> +             int aio_writev(
>>>>> +                 _Inout_ struct aiocb *aiocbp
>>>>> +             );
>>>>> +     }
>>>>> +259  AUE_AIO_READV   STD {
>>>>> +             int aio_readv(
>>>>> +                 _Inout_ struct aiocb *aiocbp
>>>>> +             );
>>>>> +     }
>>>>> +260-271      AUE_NULL        UNIMPL  nosys
>>>>> 272   AUE_O_GETDENTS  COMPAT11 {
>>>>>               int getdents(
>>>>>                   int fd,
>>>>
>>>> Should these not be added to the end?
>>>>
>>>> Jess
>>>>
>>>
>>> Should they be?  I'm not aware of any requirement to add new syscalls to
>>> the end.  I put them here so they would be next to the other AIO
>> syscalls.
>>
>> Yes.  I'm sorry I missed this in the review.  It's vastly easier to audit
>> these files and address conflicts if they are append-only.  We're also
>> using these syscall numbers internally specifically to avoid conflicts
>> with new syscalls.  Please move them to the end.
>>
>> I do see that we only provide extremely outdated advice in the comments
>> of syscalls.master.  I'll take a look at improving this and the wiki
>> page.
>>
>> Thanks,
>> Brooks
>>
> 
> Ok, I'll move them.  And could you please elaborate on how we're "using
> these syscall numbers internally"?

CheriBSD has some custom syscalls for testing in those slots.  There's
not really a way you could have known that though.  The comments in
syscalls.master are not always helpful.  For example, the comment above
250 is not clear at all.  It was added in r14219 and only applied to 250
and 251 at the time.  r244439 added 252-254 which do seem to fall under
that umbrella, and then r25537 add a big blob of reserved slots so
FreeBSD system calls started at 300, but without really defining what
the range was for.  Presumably it was for OpenBSD/NetBSD compat still, but
we also abandoned that idea entirely in r330517.  Since the comment is
worded poorly some folks read it as reserving a larger range, see commit
r152845 for example which doesn't seem merited given the history (and given
that r151867 was not similarly asked to be reverted).

Humm, that comment was removed in r330517 and then brought back in r332086.

I do think we should explicitly reserve our existing holes for "vendor"
system calls that forks can use without having to worry about future
conflicts.

-- 
John Baldwin