Proper way to add vendor-specific syscalls?

[Alan Somers]

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