Date: Sun, 9 Nov 2008 22:46:39 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Ed Schouten <ed@80386.nl> Cc: FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: pipe(2) calling convention: why? Message-ID: <20081109204639.GQ18100@deviant.kiev.zoral.com.ua> In-Reply-To: <20081109203848.GP18100@deviant.kiev.zoral.com.ua> References: <20081109192746.GO1165@hoeg.nl> <20081109203848.GP18100@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081109204639.GQ18100>