-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 inte
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
> > nex
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 cop
-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 colocate
* 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 syscal
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 f
-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 y
-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()
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 indirect
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 solu
-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:
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 c
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.
14 matches
Mail list logo
