This is a discussion on Re: pipe(2) calling convention: why? - FreeBSD ; Looks really good, simplifies and reduces code. * Ed Schouten [081109 11:27] 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 ...
Looks really good, simplifies and reduces code.
* Ed Schouten
[081109 11:27] 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
> 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.
> 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?
> Ed Schouten
> WWW: http://80386.nl/
- Alfred Perlstein
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"