-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dean gaudet wrote:
> as an application writer how do i access accept(2) with FD_CLOEXEC
> functionality? will glibc expose an accept2() with a flags param?
Not yet decided. There is the alternative to extend the accept()
interface to have both
On Mon, 19 Nov 2007, Ingo Molnar wrote:
>
> * Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > I do see a problem, because some readers will take your example as a
> > reference, as it will probably sit in a page that
> > google^Wsearch_engines will bring at the top of search results for
> >
On Mon, 19 Nov 2007, Ingo Molnar wrote:
* Eric Dumazet [EMAIL PROTECTED] wrote:
I do see a problem, because some readers will take your example as a
reference, as it will probably sit in a page that
google^Wsearch_engines will bring at the top of search results for
next ten years
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dean gaudet wrote:
as an application writer how do i access accept(2) with FD_CLOEXEC
functionality? will glibc expose an accept2() with a flags param?
Not yet decided. There is the alternative to extend the accept()
interface to have both
Ulrich Drepper wrote:
But I still don't see that the magic encoding is a valid solution, it
doesn't address the limited parameter number. Plus, using sys_indirect
could in future be used to transport entire parameters (like a sigset_t)
along with other information, thereby saving individual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
> What bothers me about the sys_indirect approach is that it will get
> increasingly expensive as time goes on, and in doing so it does a
> user-space memory reference, which are extra expensive. The extra table
> can be
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
> I do see a problem, because some readers will take your example as a
> reference, as it will probably sit in a page that
> google^Wsearch_engines will bring at the top of search results for
> next ten years or so.
>
> (I bet for "sys_indirect
On Mon, 19 Nov 2007 07:48:23 -0800
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Dumazet wrote:
> > So when you recompile your old program (as you post it and as I commented
> > on),
> > it will pass a >= 12 bytes data to kernel, with only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
> So when you recompile your old program (as you post it and as I commented on),
> it will pass a >= 12 bytes data to kernel, with only first 4 bytes set to
> O_CLOEXEC.
>
> Other bytes will contain junk
If you don't initialize
On Mon, 19 Nov 2007 07:12:29 -0800
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Dumazet wrote:
> >> union indirect_params i;
> >> i.file_flags.flags = O_CLOEXEC;
> >
> > This setup forbids future addons to file_flags
> >
> > In three
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
>> union indirect_params i;
>> i.file_flags.flags = O_CLOEXEC;
>
> This setup forbids future addons to file_flags
>
> In three years, when we want to add a new indirect feature to socket()
> call, do we need a new
On Sat, 17 Nov 2007 00:31:36 -0500
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
>
> union indirect_params i;
> i.file_flags.flags = O_CLOEXEC;
This setup forbids future addons to file_flags
In three years, when we want to add a new indirect feature to socket()
call, do we need a new
On Sat, 17 Nov 2007 00:31:36 -0500
Ulrich Drepper [EMAIL PROTECTED] wrote:
union indirect_params i;
i.file_flags.flags = O_CLOEXEC;
This setup forbids future addons to file_flags
In three years, when we want to add a new indirect feature to socket()
call, do we need a new indirect2()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
union indirect_params i;
i.file_flags.flags = O_CLOEXEC;
This setup forbids future addons to file_flags
In three years, when we want to add a new indirect feature to socket()
call, do we need a new indirect2() syscall
On Mon, 19 Nov 2007 07:12:29 -0800
Ulrich Drepper [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
union indirect_params i;
i.file_flags.flags = O_CLOEXEC;
This setup forbids future addons to file_flags
In three years, when we want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
So when you recompile your old program (as you post it and as I commented on),
it will pass a = 12 bytes data to kernel, with only first 4 bytes set to
O_CLOEXEC.
Other bytes will contain junk
If you don't initialize the
On Mon, 19 Nov 2007 07:48:23 -0800
Ulrich Drepper [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
So when you recompile your old program (as you post it and as I commented
on),
it will pass a = 12 bytes data to kernel, with only first 4 bytes
* Eric Dumazet [EMAIL PROTECTED] wrote:
I do see a problem, because some readers will take your example as a
reference, as it will probably sit in a page that
google^Wsearch_engines will bring at the top of search results for
next ten years or so.
(I bet for sys_indirect syscall -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
What bothers me about the sys_indirect approach is that it will get
increasingly expensive as time goes on, and in doing so it does a
user-space memory reference, which are extra expensive. The extra table
can be colocated
Ulrich Drepper wrote:
But I still don't see that the magic encoding is a valid solution, it
doesn't address the limited parameter number. Plus, using sys_indirect
could in future be used to transport entire parameters (like a sigset_t)
along with other information, thereby saving individual
Ulrich Drepper wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
It seems to me that we could accomplish the same thing by passing the
number of parameters in the upper bits of the system call number
register (%eax in the case of x86.)
This isn't really a generic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
> It seems to me that we could accomplish the same thing by passing the
> number of parameters in the upper bits of the system call number
> register (%eax in the case of x86.)
This isn't really a generic solution. The number
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
It seems to me that we could accomplish the same thing by passing the
number of parameters in the upper bits of the system call number
register (%eax in the case of x86.)
This isn't really a generic solution. The number of
Ulrich Drepper wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
It seems to me that we could accomplish the same thing by passing the
number of parameters in the upper bits of the system call number
register (%eax in the case of x86.)
This isn't really a generic
Ulrich Drepper wrote:
wing patches provide an alternative implementation of the
sys_indirect system call which has been discussed a few times.
This no system call allows us to extend existing system call
interfaces with adding more system calls.
Davide's previous implementation is IMO far more
Ulrich Drepper wrote:
wing patches provide an alternative implementation of the
sys_indirect system call which has been discussed a few times.
This no system call allows us to extend existing system call
interfaces with adding more system calls.
Davide's previous implementation is IMO far more
wing patches provide an alternative implementation of the
sys_indirect system call which has been discussed a few times.
This no system call allows us to extend existing system call
interfaces with adding more system calls.
Davide's previous implementation is IMO far more complex than
warranted.
wing patches provide an alternative implementation of the
sys_indirect system call which has been discussed a few times.
This no system call allows us to extend existing system call
interfaces with adding more system calls.
Davide's previous implementation is IMO far more complex than
warranted.
28 matches
Mail list logo
