Re: [PATCH] alternative to sys_indirect, part 1

[Linus Torvalds]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/