Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets

H. Peter Anvin
2007-11-20T23:58:40Z

Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> wrote:
>
>>> Why not just pin down the current ABI that there's 6 syscall
>>> parameters _and not more_?
>> Because we have already violated it. There are system calls that need
>> more than 6 arguments: we need *a* convention. Worse, we're not
>> actually talking 6 *arguments*, we're talking 6 *words*; on 32-bit
>> platforms a single argument can occupy two words.
>
> i think you are at least partly wrong here. Multiplexing/demultiplexing
> can go on infinitely - for example sys_write(fd, size, buf) can be
> thought of as a function call that passes in fd, size and a variable
> number of arguments of the data to be written.
>
> in that sense capping function arguments at 6 is _sensible_ because it
> prefers _simple_ interfaces. When i wrote syslets i did a syscall number
> of arguments histogram:
>
> #args #syscalls
> -----------------
> 0 22
> 1 51
> 2 83
> 3 85
> 4 40
> 5 23
> 6 8
>
> Fortunately what we see today is that 80% of all syscalls have 4 or less
> parameters. (yes, there are a few 6-parameter syscalls that arguably
> hurt, but still, it's the exception not the rule)
>
> this histogram shows a healthy bell curve which is _not_ limited by the
> arguments limit of 6, but by common sense! If the 6-arguments limit was
> a problem then we'd see a pile-up of 6-param syscalls.
>
> so i believe you should start thinking about lots-of-arguments syscalls
> as an exception not as something that needs to fit into some generic
> ABI. (Especially as most schemes that were supposed to handle this
> problem would hurt the sane 4-parameter (or less) syscall case too.)
>

I guess I'm confused here... all I said was I wanted them to be
systematic, and not need ad-hoc interfaces. In particular, I really
don't want to see an interface where "oh, the fifth parameter is really
a flags field so it's passed with sys_indirect, and is only accessible
via a sys_indirect" is the norm.

We don't have all that many; pselect() being the main one (I think there
might be a handful more on 32-bit platforms, but not positive.) It
introduced the convention of pointing argument register 6 to a
user-space data structure. Simple, and as you correctly point out, it's
a comparatively rare case. In klibc, I currently handle it as a special
case, but I would prefer to avoid special cases of that sort going forward.

Note that on s390, 6-parameter system calls are already a special case:
anything with over 5 parameters is invoked via a memory structure. This
actually means that for pselect on s390, we indirect via a memory
structure not once, but twice, for no good reason.

-hpa