pipe(2) calling convention: why?

[Kostik Belousov]

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,
> > 
> > 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.
> > 
> > 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.
> > 
> > In my opinion there are a couple of disadvantages of having multiple
> > return values:
> > 
> > - As documented in syscall(2), there is no way to obtain the second
> >   return value if you use this functions.
> > 
> > - 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?
> > 
> > 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.
> > 
> > I could commit this if people think it makes sense. Any comments?
> > 
> 
> 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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20081109/1595846f/attachment.pgp