-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
13 matches
Mail list logo
