From: "H. Peter Anvin" <hpa@zytor.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Ulrich Drepper <drepper@redhat.com>,
David Miller <davem@davemloft.net>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
tglx@linutronix.de
Subject: Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets
Date: Mon, 26 Nov 2007 11:07:12 -0800 [thread overview]
Message-ID: <474B1960.2030104@zytor.com> (raw)
In-Reply-To: <20071126184528.GA16071@elte.hu>
Ingo Molnar wrote:
>
> So it's not like sys_indirect() would break some magic pristine state of
> a flat parameter space - on the contrary, most of the nontrivial
> syscalls take pointers to structures or pointers to streams of
> information. The parameter count histogram i believe further underlines
> this point:
>
> #args #syscalls
> -----------------
> 0 22
> 1 51
> 2 83
> 3 85
> 4 40
> 5 23
> 6 8
>
> the natural 'center' of function call parameter counts is around 1-4
> parameters, and that is natural. (most operators that the human brain
> prefers to operate with are like that - having higher complexity than
> that often defeats the purpose of getting an API used by ... humans.)
>
I was preparing a response to Linus' email, but I really feel this needs
to be addressed specifically.
When it comes to dealing with the operator-visible state, what matters
is what happens on the API level, NOT on the system call level.
Furthermore, the proposed sys_indirect interface just means that there
are parameters hidden from immediately view, even though they
fundamentally change the operation performed, and that it is much harder
to correlate, say, the output of strace(1) with what actually happened
in the program. So from a *psychological* point of view, this seems to
be an insane design choice.
-hpa
next prev parent reply other threads:[~2007-11-26 19:08 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
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 [this message]
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=474B1960.2030104@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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