From owner-freebsd-hackers@freebsd.org Tue Oct 4 00:14:59 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 443F4AF3A07 for ; Tue, 4 Oct 2016 00:14:59 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 155071AD; Tue, 4 Oct 2016 00:14:59 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: by mail-pa0-x22f.google.com with SMTP id ik13so13290145pac.2; Mon, 03 Oct 2016 17:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1/1qv5OOX0K8Yd2vLX9Ae+uSdp6T5ZpZkK2FT64rlbQ=; b=Q6hkE2bF8qePsGaKDqDgrHdg2CHBQhPb57Ub6X9PbZOQhlUU1KQLnC7wdAfJiURIB0 AVuKfeacTYIKkUc66MLrX6uHjPbI+6ibH4yZ+CpW0YYaBZtBzyQ9Z4ABzlOWPsNcNKx6 6TJZ4/uamhE9wUuXFeMYhYVlObWPgou1aRZ6lmMUOWnTsPwWDO3nhHsifcmb+b3Wowy7 uJ4hcrSzIoiKsN93tUWUoqRmG0kH/Z9brJPENoXXRbppek/JuU2RFr0pn/9O/biwt2pG zaXCpmrNLKPAIn4SMOjIy+nNWmcgj313oix3TRIv2wCgXRrmp+kYaIXh1mQsJ+M3tp1E 5h7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1/1qv5OOX0K8Yd2vLX9Ae+uSdp6T5ZpZkK2FT64rlbQ=; b=IEkrHp+TWGfWu1B3WfBc0/TR6NSiX4LFph5CF6YhxZSzwbyt3Vzt0Mc02n/x0GCC8F Y7q4MoGgLCv3HERuIlLpWKsngMOIEwAYAbao8hRtP/cyS1P/dUVwphpXI62/V4cabQKH CE1Yd9oNFm0+w5rDKorOmWmWqyALJJZ3XYpxcrcTv2eA4A4/iIv7srQd5IOwhZYYZiSf hGwB0OWv5Bw4IvyF0kwFG/X0zLfZ4gAUFmLf29m8RhnMXy/ljO+sT3tSSJa6WOlqWAw/ XnxhK8HFjxbxwCLeYSyhkJm96wsZi2ew7XRHfWUSNJqNNnKDvXgTCAwQfQG60iXnF/hq VP8w== X-Gm-Message-State: AA6/9Rk5XTnnyGxEF93eHvec9oTPx5HUfdFl3WMUZxXy2AjcBxfrlD0s3xf4PrNUjHqfb+SrzPFb6u2i/so6lA== X-Received: by 10.66.26.49 with SMTP id i17mr1054433pag.145.1475540098585; Mon, 03 Oct 2016 17:14:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.217.136 with HTTP; Mon, 3 Oct 2016 17:14:58 -0700 (PDT) In-Reply-To: References: <20161003181803.GS38409@kib.kiev.ua> From: Cedric Blancher Date: Tue, 4 Oct 2016 02:14:58 +0200 Message-ID: Subject: Re: Proper way to add vendor-specific syscalls? To: Alan Somers Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 00:14:59 -0000 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. Ced On 4 October 2016 at 02:03, Alan Somers 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 > 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 wrote: >>> On Mon, Oct 3, 2016 at 12:18 PM, Konstantin Belousov >>> 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@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> >> >> -- >> Cedric Blancher >> [https://plus.google.com/u/0/+CedricBlancher/] >> Institute Pasteur -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur