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

["H. Peter Anvin" <hpa@zytor.com>]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/