From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 21:35:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98692735 for ; Wed, 3 Sep 2014 21:35:13 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37AE319D6 for ; Wed, 3 Sep 2014 21:35:12 +0000 (UTC) X-AuditID: 12074425-f79e46d000002583-50-5407885ccbc3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 45.79.09603.C5887045; Wed, 3 Sep 2014 17:30:04 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s83LU3Bx016423; Wed, 3 Sep 2014 17:30:04 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s83LU1o0017311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Sep 2014 17:30:03 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s83LU1N2001229; Wed, 3 Sep 2014 17:30:01 -0400 (EDT) Date: Wed, 3 Sep 2014 17:30:01 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Steven Stewart-Gallus Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hRV1o3pYA8xWLFE2WL75n+MFjM/z2N3 YPKY8Wk+i8fJf29ZApiiuGxSUnMyy1KL9O0SuDJ6VvxmLXjMU/F54x22BsZuri5GDg4JAROJ 1U/duxg5gUwxiQv31rN1MXJxCAnMZpLYdmYpI4SzgVGi5cN7qMxBJom1TbdZQFqEBOol9nfe YwOZxCKgJdE40RMkzCagJvF4bzMrxFRFic2nJjGD2CICNhL/2mawgdjMAvISFzYfYgSxhQXC JTbtXAU2klPAUOLm08nsIDavgKPE7AO9UEf0MEr8XtcMViQqoCOxev8UFogiQYmTM5+wQAzV klg+fRvLBEahWUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdK10MvNLNFLTSndxAgK YHYX1R2MEw4pHWIU4GBU4uFdEMAWIsSaWFZcmXuIUZKDSUmUd20de4gQX1J+SmVGYnFGfFFp TmrxIUYJDmYlEd6aWqAcb0piZVVqUT5MSpqDRUmc9621VbCQQHpiSWp2ampBahFMVoaDQ0mC V78dqFGwKDU9tSItM6cEIc3EwQkynAdoeFkbyPDigsTc4sx0iPwpRl2OdZ3f+pmEWPLy81Kl xHlTQIoEQIoySvPg5sASzytGcaC3hHnfg1TxAJMW3KRXQEuYgJa45bCCLClJREhJNTB6GHGd 6O99u1XK+nb94mVbc46v5jvgdXAjv9Q5wY/ZnYnTt7OYmuS4LQhd73CKSVv6zvXAk5/ezV4d 4aDWeeyb2K26XbP2W377mh23+Nj79alTjBO2v2G9EWbQsMzy0NnwJQ96vu25xyZ1fi3bDYkj x1LtU1fMvGGgETpzuf3yVQVVMUxLTaKTlViKMxINtZiLihMBNBXrRxcDAAA= Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:35:13 -0000 On Thu, 28 Aug 2014, Steven Stewart-Gallus wrote: > > svn blame says that the whole implementation dates from r1541. > > Looks like > > it was never implemented. Some googling indicates that it was a > > plannedroutine to set the stack size, which was never implemented, > > anywhere. > > > The locking comments were added in r79224, but the implementation is > > otherwise from r1541, i.e., it was never implemented. > > Alright, so sys/kern/syscalls.master can be patched somewhat like so > and I won't need to document them? > > -72 AUE_O_VADVISE STD { int ovadvise(int anom); } vadvise \ > - ovadvise_args int > +72 AUE_NULL OBSOL ovadvise > > -70 AUE_SSTK STD { int sstk(int incr); } > +70 AUE_SSTK OBSOL sstk I don't think so; I think that would be a regression. We do currently provide implementations for these syscalls, that just happen to always return failure. I think that the OBSOL annotation corresponds to a complete lack of implementation. Perhaps it would be acceptable at a major release boundary, but this is not my area of expertise. > Okay, Linux has similar reserved system calls such as tuxcall. Linux > deals with these by having an unimplemented.2 manpage which lists > obsolete or reserved system calls. So we can just add to the manpage > stuff like: afs3_syscall is a system call reserved for the use of the > OpenAFS people. I don't have any particular objection to such a thing existing, but I wonder whether the developer time to create it could be better used on other things. I guess it comes down to what value it is seen as providing. -Ben