From owner-freebsd-arch@FreeBSD.ORG Sun Nov 9 21:14:06 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 647F01065673 for ; Sun, 9 Nov 2008 21:14:06 +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 0C2E98FC17 for ; Sun, 9 Nov 2008 21:14:06 +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 1KzHBC-0009D3-Mp; Sun, 09 Nov 2008 22:46:42 +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 mA9KkdDh073356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 22:46:40 +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 mA9KkdV3081989; Sun, 9 Nov 2008 22:46:39 +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 mA9Kkdbs081988; Sun, 9 Nov 2008 22:46:39 +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:46:39 +0200 From: Kostik Belousov To: Ed Schouten Message-ID: <20081109204639.GQ18100@deviant.kiev.zoral.com.ua> References: <20081109192746.GO1165@hoeg.nl> <20081109203848.GP18100@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fxAWlMnXhsHl2yhM" Content-Disposition: inline In-Reply-To: <20081109203848.GP18100@deviant.kiev.zoral.com.ua> 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 1KzHBC-0009D3-Mp 8f6e96d609e66d01e73cae4546665334 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:06 -0000 --fxAWlMnXhsHl2yhM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 09, 2008 at 10:38:48PM +0200, Kostik Belousov wrote: > 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 >=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). >=20 > 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. >=20 > 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. Part that updates man page, introduces kern_pipe and simplifies linuxolator has a stand-alone value. I think that should be committed in any case. --fxAWlMnXhsHl2yhM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkkXTC4ACgkQC3+MBN1Mb4j3bACgtXJaWLeNc5TRBHVTSt6Tvbww MeQAnRIVSUsDJEJ7my/m3NPMgLFKxWKJ =vyWd -----END PGP SIGNATURE----- --fxAWlMnXhsHl2yhM--