Date: Tue, 4 Oct 2016 09:59:04 +0900 From: Ngie Cooper <yaneurabeya@gmail.com> To: Cedric Blancher <cedric.blancher@gmail.com> Cc: Alan Somers <asomers@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Proper way to add vendor-specific syscalls? Message-ID: <29E3A158-C3E0-45F0-8275-A0030B7CB6D4@gmail.com> In-Reply-To: <CALXu0UfhNQ7Dm8C=QYAgatvonqV8pmeKjLSRMNQkTdGT25t4gQ@mail.gmail.com> References: <CAOtMX2gi0rvC85qcUb2UZRbVGB%2BS%2BeXuAzzxn50GmUV4QKKghg@mail.gmail.com> <20161003181803.GS38409@kib.kiev.ua> <CAOtMX2hCMJSUDrNw8t5rVkeH_Hs5J-Q_10vA5eYXkmGYGZYYhA@mail.gmail.com> <CALXu0UeSogSPD0vcVO1eaWJ4Vuk6yFZBjwhPVtt6ovXLvF18Fg@mail.gmail.com> <CAOtMX2gOs-qt70Xpvrd5t5sutr3XxVVb2%2BSEGDoDEM_U=fJtOQ@mail.gmail.com> <CALXu0UfhNQ7Dm8C=QYAgatvonqV8pmeKjLSRMNQkTdGT25t4gQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Oct 4, 2016, at 09:14, Cedric Blancher <cedric.blancher@gmail.com> wrot= e: >=20 > Why on earth do you need to add new syscalls? UNIX always handled such > stuff via ioctl(). >=20 > 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 c= ompatibility with standard syscalls and structures, but want to maintain bin= ary compatibility with older binaries, which means that they need to maintai= n 2 syscalls with different entry points, but a similar call path under the c= overs, 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@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. >>=20 >> -Alan >>=20 >> On Mon, Oct 3, 2016 at 5:38 PM, Cedric Blancher >> <cedric.blancher@gmail.com> wrote: >>> Why do you want to add new syscalls? The UNIX way is to add new >>> ioctl() and be done. >>>=20 >>> Typically new syscalls need committee approval, to prevent that every >>> crazy idea gets a new syscall and thus litters that namespace. >>>=20 >>> Ced >>>=20 >>>> On 3 October 2016 at 22:00, alan somers <asomers@gmail.com> wrote: >>>> On Mon, Oct 3, 2016 at 12:18 PM, Konstantin Belousov >>>> <kostikbel@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. >>>>>=20 >>>>>> 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? >>>>>=20 >>>>> Each nosys syscall increases the size of the default ABI syscalls tabl= e. >>>>> On amd64 sizeof(struct sysent) =3D=3D 48, adding 100 nosys entries wou= ld >>>>> waste a page and some more. >>>>>=20 >>>>> How many syscalls do you need ? You probably do not allow random modu= les >>>>> loaded and implementing syscalls, so could you use e.g. range 210-219 ?= >>>>>=20 >>>>> 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. >>>>=20 >>>> Ok, it sounds like filling holes is the best method. Thanks for the >>>> advice, kib. >>>>=20 >>>> -Alan >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >>>=20 >>>=20 >>>=20 >>> -- >>> Cedric Blancher <cedric.blancher@gmail.com> >>> [https://plus.google.com/u/0/+CedricBlancher/] >>> Institute Pasteur >=20 >=20 >=20 > --=20 > Cedric Blancher <cedric.blancher@gmail.com> > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29E3A158-C3E0-45F0-8275-A0030B7CB6D4>