[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071126184528.GA16071@elte.hu>
Date: Mon, 26 Nov 2007 19:45:28 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Ulrich Drepper <drepper@...hat.com>,
David Miller <davem@...emloft.net>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
tglx@...utronix.de
Subject: Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets
* Linus Torvalds <torvalds@...ux-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists