From: Ingo Molnar <mingo@elte.hu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Zach Brown <zach.brown@oracle.com>,
Ulrich Drepper <drepper@redhat.com>,
David Miller <davem@davemloft.net>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
tglx@linutronix.de, torvalds@linux-foundation.org
Subject: Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets
Date: Wed, 21 Nov 2007 00:41:51 +0100 [thread overview]
Message-ID: <20071120234151.GD23667@elte.hu> (raw)
In-Reply-To: <47436D07.2070203@zytor.com>
* 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.)
Ingo
next prev parent reply other threads:[~2007-11-20 23:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-20 6:53 [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets Ulrich Drepper
2007-11-20 7:59 ` David Miller
2007-11-20 16:04 ` Ulrich Drepper
2007-11-20 18:13 ` H. Peter Anvin
2007-11-20 18:24 ` Zach Brown
2007-11-20 19:12 ` H. Peter Anvin
2007-11-20 22:22 ` Ingo Molnar
2007-11-20 22:33 ` Davide Libenzi
2007-11-20 22:42 ` Ingo Molnar
2007-11-20 23:25 ` H. Peter Anvin
2007-11-20 23:41 ` Ingo Molnar [this message]
2007-11-20 23:57 ` H. Peter Anvin
2007-11-26 18:17 ` Linus Torvalds
2007-11-26 18:45 ` Ingo Molnar
2007-11-26 19:07 ` H. Peter Anvin
2007-11-26 19:55 ` Davide Libenzi
2007-11-26 19:20 ` H. Peter Anvin
2007-11-26 23:25 ` Ulrich Drepper
2007-11-27 0:14 ` H. Peter Anvin
2007-11-27 0:42 ` Ulrich Drepper
2007-11-27 1:23 ` H. Peter Anvin
2007-11-27 2:14 ` Linus Torvalds
2007-11-27 2:38 ` H. Peter Anvin
2007-11-20 21:48 ` David Miller
2007-11-20 21:55 ` Zach Brown
2007-11-20 22:36 ` David Miller
2007-11-20 17:54 ` Zach Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071120234151.GD23667@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=drepper@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=zach.brown@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox