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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ingo Molnar wrote:
* H. Peter Anvin <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux