From owner-freebsd-hackers@freebsd.org Mon Oct 3 23:38:44 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 6F98AAF4BAB for ; Mon, 3 Oct 2016 23:38:44 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 420EAD96; Mon, 3 Oct 2016 23:38:44 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id 190so21750708pfv.0; Mon, 03 Oct 2016 16:38:44 -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=0xLBzoFgBnUsdcVQerVHCsdhIxsQBuLXG9Zd19z1xto=; b=dMp+rJVkqJOyJn2aqh7EH+400h8ZP+QkTtoWTLHHZ3FmP72ffucSh7r/xl1yTeoPXT 6LV2dJhZoH08yHZedIeGV2BsYwaMONvkZxdWQ6d/pokjPhQsPllq1j7Ui834a7/No1TB zhCLQP2YypxlAEaFmTbP+OxVOVw0uc0Y+XoVMMk72LwJLvJvgZfN0hw82637l9oUMMqc 3tP1iX3xXlyYdIvKG24UPQt2Sujng4VCuFgJU4MRgm+lr2rYycqYhqTByNagNQE5TGMK dvwc++OeR5gNQcLk6qK4kSIn+jWNwuTjoFCByzYtVYHn0HArN1XXwBnJ9/oin60SXZam rC/w== 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=0xLBzoFgBnUsdcVQerVHCsdhIxsQBuLXG9Zd19z1xto=; b=G3Ok1YQ75gtOMQNQAwsIkahRN3G4I8CJ+WYws2hhULVqyRARysT7mem7pS9Q/EQAdc gs+Eg4fiI2Xh13aq64KuzkGCdKA081HIH3mV4/2PKK2xqHI5rJ0gmEQ1DsTHRHFlJLBR RA7asO7X3BJXO2LSdQE9YW4D63nKvlCdMhO5yA037aBOlTb9J01iRdsAa9QiB6MS0g1A rR0kYGksa8LrryXlwi6oCvjLg1lE7T5eLeDb38Otjr0F3A1P22HH68j9EAK/digx3rSe YwucVLobFN2+Mi0+5hliIoZyXFEyZ5P0L7q6szYGKfCJ/P7PUioNiV75dsSp/4MidjAm ja5g== X-Gm-Message-State: AA6/9Rm5c58QM3io7OzNJXv/296RVwOZf3zg72lZcmI9YbEP0M6Ux4lfAfamp8y0wuFK7gpi7YEl9XZBUuU0vw== X-Received: by 10.98.64.10 with SMTP id n10mr1116310pfa.96.1475537923817; Mon, 03 Oct 2016 16:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.217.136 with HTTP; Mon, 3 Oct 2016 16:38:43 -0700 (PDT) In-Reply-To: References: <20161003181803.GS38409@kib.kiev.ua> From: Cedric Blancher Date: Tue, 4 Oct 2016 01:38:43 +0200 Message-ID: Subject: Re: Proper way to add vendor-specific syscalls? To: alan somers Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Alan Somers 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: Mon, 03 Oct 2016 23:38:44 -0000 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