[lkml]   [2008]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] alternative to sys_indirect, part 1
Hash: SHA1

Linus Torvalds wrote:
> 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,

The easy, clean cases I already handled back when. I wouldn't have
implemented socket this way to preserve the function signature but
that's just me. It's hopefully over now.

What remains isn't that easy to fix. We need syscall interface changes.
Yes, I'd like to avoid them, too. But sometimes the existing
interfaces are just wrong and now we have to make a decision: new
syscalls or sys_indirect. No way around it.

As far as the userlevel interface is concerned, this is not quite the
same. As explained before, I've anticipated some of the problems.
signalfd, eventfd have no flags parameter in the syscall but I have them
in the userlevel interface. I.e., any kernel change will be hidden. At
least as far as the interface signature is concerned.

So, the question still is on the table: do you want sys_indirect?

If yes, then then new sys_accept would use sys_indirect instead of a new
entry point. If you don't want sys_indirect, then I'll submit a new
sys_accept syscall (already have the patch here ready to go).

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Version: GnuPG v1.4.7 (GNU/Linux)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-04-24 18:57    [W:0.074 / U:34.892 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site