Proper way to add vendor-specific syscalls?

[Ngie Cooper]

> On Oct 4, 2016, at 09:14, Cedric Blancher <cedric.blancher at gmail.com> wrote:
> 
> Why on earth do you need to add new syscalls? UNIX always handled such
> stuff via ioctl().
> 
> Why do you think an ioctl() is not sufficient in your case? Its
> basically the same as a syscall.

I can't speak to Alan's case, but sometimes vendors explicitly break binary compatibility with standard syscalls and structures, but want to maintain binary compatibility with older binaries, which means that they need to maintain 2 syscalls with different entry points, but a similar call path under the covers, eg having a 64 bit inode_t requires maintaining 2 copies of stat. One that can deal with 32-bit inode_t and 64-bit inode_t.

Cheers,
-Ngie

>> On 4 October 2016 at 02:03, Alan Somers <asomers at freebsd.org> wrote:
>> In this case, I'm working with vendor-specific syscalls.  They'll
>> never be exposed outside of my organization, so I don't have to worry
>> about polluting the FreeBSD namespace.  I do, however, have to worry
>> about FreeBSD additions interfering with the vendor-specific syscalls.
>> 
>> -Alan
>> 
>> On Mon, Oct 3, 2016 at 5:38 PM, Cedric Blancher
>> <cedric.blancher at gmail.com> wrote:
>>> Why do you want to add new syscalls? The UNIX way is to add new
>>> ioctl() and be done.
>>> 
>>> Typically new syscalls need committee approval, to prevent that every
>>> crazy idea gets a new syscall and thus litters that namespace.
>>> 
>>> Ced
>>> 
>>>> On 3 October 2016 at 22:00, alan somers <asomers at gmail.com> wrote:
>>>> On Mon, Oct 3, 2016 at 12:18 PM, Konstantin Belousov
>>>> <kostikbel at gmail.com> wrote:
>>>>> On Mon, Oct 03, 2016 at 11:48:39AM -0600, Alan Somers wrote:
>>>>>> What's the proper way to add a vendor-specific syscall? The comments
>>>>>> in kern/syscalls.master suggest that they should be put in the range
>>>>>> from 151-180, but most of that range is actually occupied.
>>>>> I think that the 'vendors' there means vendors of other BSD-derived
>>>>> systems and not e.g. an appliance vendors.
>>>>> 
>>>>>> Only five
>>>>>> nosys slots are available.  If I add syscalls to the end of the list,
>>>>>> they'll likely collide with future standard syscalls.  Should I just
>>>>>> added ~100 nosys syscalls to the end of the list, and put my custom
>>>>>> syscalls afterwards?  Is there any penalty to lengthening the list?
>>>>> 
>>>>> Each nosys syscall increases the size of the default ABI syscalls table.
>>>>> On amd64 sizeof(struct sysent) == 48, adding 100 nosys entries would
>>>>> waste a page and some more.
>>>>> 
>>>>> How many syscalls do you need ?  You probably do not allow random modules
>>>>> loaded and implementing syscalls, so could you use e.g. range 210-219 ?
>>>>> 
>>>>> If you look further, you will see lot of holes like 258-271, 281-288
>>>>> etc.  Current practice is to allocate new syscalls at the end of the
>>>>> table, which leaves there holes unused with high chance of never being
>>>>> collected.
>>>> 
>>>> Ok, it sounds like filling holes is the best method.  Thanks for the
>>>> advice, kib.
>>>> 
>>>> -Alan
>>>> _______________________________________________
>>>> freebsd-hackers at freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>>> 
>>> 
>>> 
>>> --
>>> Cedric Blancher <cedric.blancher at gmail.com>
>>> [https://plus.google.com/u/0/+CedricBlancher/]
>>> Institute Pasteur
> 
> 
> 
> -- 
> Cedric Blancher <cedric.blancher at gmail.com>
> [https://plus.google.com/u/0/+CedricBlancher/]
> Institute Pasteur
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"