From owner-freebsd-arch@FreeBSD.ORG Sun Nov 9 21:14:05 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC430106564A for ; Sun, 9 Nov 2008 21:14:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 640A88FC0A for ; Sun, 9 Nov 2008 21:14:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KzH3c-0008k1-GD; Sun, 09 Nov 2008 22:38:52 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mA9Kcmdw072933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 22:38:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mA9Kcmwu081746; Sun, 9 Nov 2008 22:38:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mA9KcmtO081745; Sun, 9 Nov 2008 22:38:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 Nov 2008 22:38:48 +0200 From: Kostik Belousov To: Ed Schouten Message-ID: <20081109203848.GP18100@deviant.kiev.zoral.com.ua> References: <20081109192746.GO1165@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k6ZcKdd3yPXXXL9P" Content-Disposition: inline In-Reply-To: <20081109192746.GO1165@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KzH3c-0008k1-GD b8f941f6187919ab3e07f2bcfd5a1ba2 X-Terabit: YES Cc: FreeBSD Arch Subject: Re: pipe(2) calling convention: why? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2008 21:14:05 -0000 --k6ZcKdd3yPXXXL9P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 09, 2008 at 08:27:46PM +0100, Ed Schouten wrote: > Hello all, >=20 > After having a discussion on IRC with some friends of mine about system > call conventions, we couldn't exactly determine why pipe(2)'s calling > convention has to be different from the rest. Unlike most system calls, > pipe(2) has two return values. Instead of just copying out an array of > two elements, it uses two registers to store the file descriptor > numbers. >=20 > It seems a lot of BSD-style system calls used to work that way, but > pipe(2) seems to be the only system call on FreeBSD that uses this > today. Some system calls only seem to set td_retval[1] to zero, which > makes little sense to me. Maybe those assignments can be removed. >=20 > In my opinion there are a couple of disadvantages of having multiple > return values: >=20 > - As documented in syscall(2), there is no way to obtain the second > return value if you use this functions. >=20 > - Each of those system calls needs to have its own implementation > written in assembly for each architecture we support. Why can hundreds > of system calls be handled in a generic fashion, while interfaces like > pipe(2) can't? >=20 > As a small experiment I've written a patch to allocate a new system call > (506) which uses a generic calling convention to implement pipe(2). It > seems Linux also uses this method, so I've removed linux_pipe() from the > Linuxolator as well, which seems to work. >=20 > I could commit this if people think it makes sense. Any comments? >=20 The convention of returning pipe descriptors in the registers comes back at least to the Six Edition. Check the Lion' book for the reference. Amusingly, Solaris uses the same calling convention for pipe(2). I do not see what we gain by the change. Now, we have one syscall and some arch-dependend wrappers in the libc. After the patch, we get rid of the wrappers, but grow two syscalls. The only reason of doing this I can imagine is to allow syscall(2) to work for SYS_pipe from C code. Since we did not heard complaints about this for ~15 years, we can live with it. --k6ZcKdd3yPXXXL9P Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkkXSlgACgkQC3+MBN1Mb4grDwCg93mTTWc9KOqwgGNjq9Lu5YDm fFMAn2ESdGhNL+Wd3yNLJa0qFpuCO7+8 =xH8s -----END PGP SIGNATURE----- --k6ZcKdd3yPXXXL9P--