Re: pipe(2) calling convention: why?
Kostik Belousov wrote:[color=blue]
> On Sun, Nov 09, 2008 at 08:27:46PM +0100, Ed Schouten wrote:[color=green]
>> 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
>> 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 to zero, which
>> makes little sense to me. Maybe those assignments can be removed.[/color][/color]
don't forget that we will still need to support the old convention
because we support running old binaries "forever" (generally).
I occasionally run freebsd 1.0 binaries on -current
(you should see how fast a "make world" is in a 1.0 chroot!)
>> 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.[/color]
[email]firstname.lastname@example.org[/email] mailing list
To unsubscribe, send any mail to "email@example.com"