generated files (Re: Does FreeBSD have sendmmsg or recvmmsg system calls?)

[Luigi Rizzo]

I wonder how complex it would be to autogenerate
at least part of the various components required
when adding a syscall like this.

It looks like the number of places to touch (see chunks
below) and the ordering constraints make the manual process very prone
to errors.

This said, it might be nice to add some explanation
in the various places, e.g. Symbol.map could do
with a comment describing the meaning of the various
groups FBSD_1.0 FBSD_1.1 FBSDprivate_1.0 and so on.

cheers
luigi

On Thu, Jan 7, 2016 at 2:54 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Thu, Jan 07, 2016 at 12:28:32PM +0200, Boris Astardzhiev wrote:
> See inline comments and final notes at the end.
>
>> diff --git a/lib/libc/include/libc_private.h b/lib/libc/include/libc_private.h
>> index 5caf9a3..7e2a902 100644
>> --- a/lib/libc/include/libc_private.h
>> +++ b/lib/libc/include/libc_private.h
>> @@ -200,8 +200,10 @@ enum {
>>       INTERPOS_pselect,
>>       INTERPOS_recvfrom,
>>       INTERPOS_recvmsg,
>> +     INTERPOS_recvmmsg,
>>       INTERPOS_select,
>>       INTERPOS_sendmsg,
>> +     INTERPOS_sendmmsg,
>>       INTERPOS_sendto,
>>       INTERPOS_setcontext,
>>       INTERPOS_sigaction,
> The interposing table must be extended at the end, and not in the middle.
> otherwise you introduce too large inconsistence with older libthr.
>
> That said, you changed libc table, but did not updated libthr.  The result
> is random segfaults in the multithreaded processes.
>
>> diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map
>> index 7b3257c..6cc3c6e 100644
>> --- a/lib/libc/sys/Symbol.map
>> +++ b/lib/libc/sys/Symbol.map
>> @@ -220,6 +220,7 @@ FBSD_1.0 {
>>       reboot;
>>       recvfrom;
>>       recvmsg;
>> +     recvmmsg;
>>       rename;
>>       revoke;
>>       rfork;
>> @@ -240,6 +241,7 @@ FBSD_1.0 {
>>       semsys;
>>       sendfile;
>>       sendmsg;
>> +     sendmmsg;
>>       sendto;
>>       setaudit;
>>       setaudit_addr;
> The versioning is wrong, new non-private symbols for 11.0 go into _1.4.
>