Linus Torvalds wrote:
The 6-word limit is a red herring. There is at least two ways to deal with it
(and this doesn't mean wiping the legacy stuff we already have):
- Let each architecture pick a calling convention and redefine the
architecture-independent bits to take an arbitrary number of
On Mon, 26 Nov 2007, H. Peter Anvin wrote:
>
> I'm presuming you're not talking about some sort of syslets/fibrils/threadlets
> here (executing an interpreted thread of execution in kernel space). That's a
> whole separate ball of wax.
Indeed.
I'm hoping that just dies. It's too complex. But
Ulrich Drepper wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
No.
I already said I'm not looking at changing the calling convention for
existing syscalls.
I did not suggest or ask for that at all.
I was asking you to consider the real implementation details for a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
> No.
>
> I already said I'm not looking at changing the calling convention for
> existing syscalls.
I did not suggest or ask for that at all.
I was asking you to consider the real implementation details for a new
syscall mecha
Ulrich Drepper wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
The 6-word limit is a red herring. There is at least two ways to deal
with it (and this doesn't mean wiping the legacy stuff we already have):
- Let each architecture pick a calling convention and redefi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
> The 6-word limit is a red herring. There is at least two ways to deal
> with it (and this doesn't mean wiping the legacy stuff we already have):
>
> - Let each architecture pick a calling convention and redefine the
> architec
On Mon, 26 Nov 2007, H. Peter Anvin wrote:
> Ingo Molnar wrote:
> >
> > 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
Linus Torvalds wrote:
On Tue, 20 Nov 2007, H. Peter Anvin wrote:
If the whole thing about "a dozen new [system calls]" then a dozen system
calls added to the existing tables are better than this mess.
No it's not.
The point about the indirect calls is that we can do it for other things
than
Ingo Molnar wrote:
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
* Linus Torvalds <[EMAIL PROTECTED]> 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
On Tue, 20 Nov 2007, H. Peter Anvin wrote:
>
> If the whole thing about "a dozen new [system calls]" then a dozen system
> calls added to the existing tables are better than this mess.
No it's not.
The point about the indirect calls is that we can do it for other things
than just a dozen rand
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Why not just pin down the current ABI that there's 6 syscall
parameters _and not more_?
Because we have already violated it. There are system calls that need
more than 6 arguments: we need *a* convention. Worse, we're not
actual
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> Why not just pin down the current ABI that there's 6 syscall
>> parameters _and not more_?
>
> Because we have already violated it. There are system calls that need
> more than 6 arguments: we need *a* convention. Worse, we're not
> actually tal
Ingo Molnar wrote:
do you suggest that extending the system call calling convention to
include an arbitrary number of parameters will solve all these API needs
we have at the moment?
if yes, then a one-shot syslet/async call would in essence be:
syslet_arg1 ... N, syscall_arg 1 ... M
* Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > whether that interpreted syslet language survives is still an open
> > question - it was extremely ugly when i wrote the first version of
> > it and it only got uglier since then :-)
>
> Aha! You admitted it finally :)
damn :-)
but if the only
From: Zach Brown <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 13:55:56 -0800
> Not to belabor this point, but it was:
>
> http://lkml.org/lkml/2007/11/20/53
>
> $ grep -l INDIRECT_PARAM .git/patches/master/*
> .git/patches/master/indirect-v4-4.patch
> .git/patches/master/indirect-v4-5.patch
> .git
On Tue, 20 Nov 2007, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> > It seems that you're doing the same thing in both cases, except you're
> > now extending it to include other random functionality, which means
> > other things than syslets are suddenly affected.
> >
> >
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> It seems that you're doing the same thing in both cases, except you're
> now extending it to include other random functionality, which means
> other things than syslets are suddenly affected.
>
> syslets are arguably a little bit different, since wh
>>> Where does this INDIRECT_PARAM() macro get defined? I do not
>>> see it being defined anywhere in these patches.
>> Defined in :
>>
>> +#define INDIRECT_PARAM(set, name) current->indirect_params.set.name
>>
>> Not my idea, I was following one review comment.
>
> This was not in the patches y
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 08:04:53 -0800
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> David Miller wrote:
> > Where does this INDIRECT_PARAM() macro get defined? I do not
> > see it being defined anywhere in these patches.
>
> Defined in :
>
> +#d
Zach Brown wrote:
That's only because you're being, deliberately or accidentally, vague
about what your actual (as opposed to imagined) requirements are.
Maybe I can help by summarizing how syslets fit in to this.
Currently the syslet patches add a single submission call which includes
an argu
> That's only because you're being, deliberately or accidentally, vague
> about what your actual (as opposed to imagined) requirements are.
Maybe I can help by summarizing how syslets fit in to this.
Currently the syslet patches add a single submission call which includes
an argument which is a
Ulrich Drepper wrote:
And I agree with all of the objections raised by both H. Pater Anvin
and Eric Dumazet.
Eric had no arguments and HP's comments lack a viable alternative proposal.
That's only because you're being, deliberately or accidentally, vague
about what your actual (as opposed
David Miller wrote:
> From: Ulrich Drepper <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2007 01:53:14 -0500
>
> FWIW, I think this indirect syscall stuff is the most ugly interface
> I've ever seen proposed for the kernel.
Well, there's no XML in /proc :) :).
But, yes, I agree that the internal code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Miller wrote:
> FWIW, I think this indirect syscall stuff is the most ugly interface
> I've ever seen proposed for the kernel.
Well, the alternative is to introduce a dozens of new interfaces. It
was Linus who suggested this alternative. Plus,
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 01:53:14 -0500
FWIW, I think this indirect syscall stuff is the most ugly interface
I've ever seen proposed for the kernel.
And I agree with all of the objections raised by both H. Pater Anvin
and Eric Dumazet.
> This patch adds sup
This patch adds support for setting the O_NONBLOCK flag of the file
descriptors returned by socket, socketpair, and accept.
socket.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
--- net/socket.c
+++ net/socket.c
@@ -362,7 +362,7 @@ static int sock_alloc_fd(struct file
27 matches
Mail list logo
