From owner-freebsd-hackers@freebsd.org Tue Oct 4 00:59:09 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 EC45CAF25E9 for ; Tue, 4 Oct 2016 00:59:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 A6E039EC; Tue, 4 Oct 2016 00:59:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id r126so219038405oib.0; Mon, 03 Oct 2016 17:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S+2Xl65ebkQSpRSJUyVw/kYcO6l4Ids4OMks8uVzDG0=; b=cxB5d59XPuOTiibMaqq+Ltj6f9oOsC4sK1qW11XwUbMEQq7/fGgaELraHsOQhkAPtz O91y6BdtS4U9AGTVsXP+kMRWE75vwTEwDFTLeDS8zRfx+72wj0RtUWb6uAZ+zct3S11d IZWQTR6FCoaQYmLRuHCN+orBVFSkaQexEH/YsH+KvZTEVczQthGqNC97nWReVRr6QpOy cw58WBoCgmmDMQq+5gqQVfpfwWgd/79W/ijItRWb/D7ug+jRfKRknyg8cCUpd0kJwocb pN0ZsEA58S57gdx0vSe3Bpgn/oUA7KkVIgTyzkVLG3X4C6RMV6ojPox+RZYj9bWz7FU4 E1uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S+2Xl65ebkQSpRSJUyVw/kYcO6l4Ids4OMks8uVzDG0=; b=iACqHcCxV3lEQzp5wWf2VFM3aJTIx3B6vfB2qgECvl81p8H+s4Viyd3nsUsLu0OsF6 jUgau8oq7zReUkYPzA9zwLZPNPXtJH5Nd2Fpj09ICm5vYDaUfGtexFDy8X3QBeB9bftB xUbLaljvxf1ZkFLCr5O7NSkbEW/QwGfZCYZKo4PKqp6/Cc32t0+dc2vcd6doSVIAhw0t 19Oy+ObKB0Y+vTCRw9KZyZKav5NB1BHGkR2Sxej5bybXHFrPdg9FenjldfH3kJnSKXOT 54g0er87vBd5HuI8IHtAlDva2QB3hAB1KHkZJn61a/PejYeljiQoTszdsG5kFUKvFF8a TN5w== X-Gm-Message-State: AA6/9RnIp1KQQNKP4jaL/DZelck3ZaD1ptX8AKT8PMyFpTdMPlf3VK9+hBOJ/6GcwEc33w== X-Received: by 10.202.188.134 with SMTP id m128mr703390oif.85.1475542748915; Mon, 03 Oct 2016 17:59:08 -0700 (PDT) Received: from [100.175.10.185] ([172.56.6.138]) by smtp.gmail.com with ESMTPSA id e22sm294444otc.16.2016.10.03.17.59.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Oct 2016 17:59:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Proper way to add vendor-specific syscalls? From: Ngie Cooper X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Tue, 4 Oct 2016 09:59:04 +0900 Cc: Alan Somers , Konstantin Belousov , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <29E3A158-C3E0-45F0-8275-A0030B7CB6D4@gmail.com> References: <20161003181803.GS38409@kib.kiev.ua> To: Cedric Blancher 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:59:10 -0000 > On Oct 4, 2016, at 09:14, Cedric Blancher 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 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 >> 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 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. >>>>>=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 >>> [https://plus.google.com/u/0/+CedricBlancher/] >>> Institute Pasteur >=20 >=20 >=20 > --=20 > Cedric Blancher > [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"=