public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	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 19:45:28 +0100	[thread overview]
Message-ID: <20071126184528.GA16071@elte.hu> (raw)
In-Reply-To: <alpine.LFD.0.9999.0711261003290.5869@woody.linux-foundation.org>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Quite frankly, I can't really see many other approaches. And of the 
> above three ones, the sys_indirect() approach really does seem to be 
> the simplest *and* the best-performing. It's basically faster to just 
> unconditionally load six registers off an indirect block than it would 
> be to have any conditionals based on which system call it is.

yeah. And even assuming for the sake of argument, that there was only 
one dominant architecture we care about, even there many of our existing 
syscall APIs are _already_ special-purpose APIs that do not encode 
parameters in a 'flat' way.

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.)

(side-note: in that sense, introducing some generic "arbitrary number of 
parameters" ABI design that was suggested instead of sys_indirect() 
would be _counter productive_ from a meta-design POV: it would not 
punish sucky, over-complicated APIs that expose way too many details in 
their main API call.)

	Ingo

  reply	other threads:[~2007-11-26 18:45 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 [this message]
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=20071126184528.GA16071@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 \
    /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