[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0804240921460.2779@woody.linux-foundation.org>
Date: Thu, 24 Apr 2008 09:30:35 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Michael Kerrisk <mtk.manpages@...il.com>
cc: David Miller <davem@...emloft.net>, alan@...rguk.ukuu.org.uk,
drepper@...hat.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] alternative to sys_indirect, part 1
On Thu, 24 Apr 2008, Michael Kerrisk wrote:
>
> It strikes me to be cleanest to use the same solution for all of them
> -- i.e., new syscalls (seems simplest) or sys_indirect() -- including
> socket().
I certainly don't dislike sys_indirect either, but I've also done user
mode programming, and when it comes to OS-specific things (and especially
if they are even _version_-specific) I can tell you that basically nobody
will ever use them if you cannot decide to use them dynamically.
Here's an example of a *successful* use of something like that:
#ifndef O_NOATIME
#define O_NOATIME 0
#endif
static unsigned int sha1_file_open_flag = O_NOATIME;
...
fd = open(filename, O_RDONLY | sha1_file_open_flag);
if (fd < 0) {
/* See if it works without O_NOATIME */
switch (sha1_file_open_flag) {
default:
fd = open(filename, O_RDONLY);
if (fd >= 0)
break;
/* Fallthrough */
case 0:
return NULL;
}
/* If it failed once, it will probably fail again.
* Stop using O_NOATIME
*/
sha1_file_open_flag = 0;
}
...
see? This is soemthing where I actually used Linux-specific code. And
dammit, I'm _Linus_. Think of your normal programmer that isn't quite as
Linux-oriented.
And that's the problem with anything that isn't flags-based. Once you do
new system calls, doing the above is really quite nasty. How do you
statically even _test_ that you have a system call? Now you need to add a
whole autoconf thing for it existing, and when it does exist you still
need to test whether it works, and you can't even do it in the slow-path
like the above (which turns the failure into a fast-path _without_ the
flag).
So while I don't dislike the indirect system call, I do think that if we
can handle a large case of the problems with an added flag to already
existing system calls, that does have huge advantages. Because it allows
code like the above, which needs absolutely zero autoconf for linking
errors etc..
Linus
--
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