On Mon, 2 Jul 2007, Ulrich Drepper wrote:
> > But there are
> > examples (and the signal stuff is one of them), where you do need the
> > set_context+syscall+unset_context abstraction, for all cases where the
> > kernel already has its own internal data strctures. In those cases you'd
> > have to
On 7/2/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
Never be usable? I made you a concrete example that is like 8 months old.
And *that* could not have been cleanly handled with the flat structure
idea.
First of all, sigmasks are not widely needed. Second, why on earth
shouldn't it be
On Mon, 2 Jul 2007, Ulrich Drepper wrote:
> On 7/1/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > With the current API design you'd able to easily confine the "pre" code
> > inside the "set" function, and the "post" code inside the "unset"
> > function. It looks pretty clean to me, and allows
On 7/1/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
With the current API design you'd able to easily confine the "pre" code
inside the "set" function, and the "post" code inside the "unset"
function. It looks pretty clean to me, and allows to limit the knowledge
of sys_indirect, the more as
On 7/1/07, Davide Libenzi [EMAIL PROTECTED] wrote:
With the current API design you'd able to easily confine the pre code
inside the set function, and the post code inside the unset
function. It looks pretty clean to me, and allows to limit the knowledge
of sys_indirect, the more as possible
On Mon, 2 Jul 2007, Ulrich Drepper wrote:
On 7/1/07, Davide Libenzi [EMAIL PROTECTED] wrote:
With the current API design you'd able to easily confine the pre code
inside the set function, and the post code inside the unset
function. It looks pretty clean to me, and allows to limit the
On 7/2/07, Davide Libenzi [EMAIL PROTECTED] wrote:
Never be usable? I made you a concrete example that is like 8 months old.
And *that* could not have been cleanly handled with the flat structure
idea.
First of all, sigmasks are not widely needed. Second, why on earth
shouldn't it be possible
On Mon, 2 Jul 2007, Ulrich Drepper wrote:
But there are
examples (and the signal stuff is one of them), where you do need the
set_context+syscall+unset_context abstraction, for all cases where the
kernel already has its own internal data strctures. In those cases you'd
have to spread
On Sun, 1 Jul 2007, Ulrich Drepper wrote:
> On 6/30/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > This is how all those overloaded syscalls looks like, BTW:
> > [...]
> > How would you do that with a single shared strcture, w/out adding in all
> > signal paths the knowledge of the structure?
On 6/30/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
This is how all those overloaded syscalls looks like, BTW:
[...]
How would you do that with a single shared strcture, w/out adding in all
signal paths the knowledge of the structure?
You said it yourself: each individual wrapper would look
On 6/30/07, Davide Libenzi [EMAIL PROTECTED] wrote:
This is how all those overloaded syscalls looks like, BTW:
[...]
How would you do that with a single shared strcture, w/out adding in all
signal paths the knowledge of the structure?
You said it yourself: each individual wrapper would look
On Sun, 1 Jul 2007, Ulrich Drepper wrote:
On 6/30/07, Davide Libenzi [EMAIL PROTECTED] wrote:
This is how all those overloaded syscalls looks like, BTW:
[...]
How would you do that with a single shared strcture, w/out adding in all
signal paths the knowledge of the structure?
You said
On Sat, 30 Jun 2007, Davide Libenzi wrote:
> Think about if we had this for the latest pselect/ppoll/epoll_pwait.
> Think about how your solution and mine would apply to that very much
> concrete case.
This is how all those overloaded syscalls looks like, BTW:
if (sigmask) {
On Sat, 30 Jun 2007, Ulrich Drepper wrote:
> On 6/30/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > But, a __get_user(), once you scrap off all the gcc wrapping, is bacially
> > a move. That could even be removed, but really I don't see the reason
> > since it allows for a cleaner strcture
On 6/30/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
But, a __get_user(), once you scrap off all the gcc wrapping, is bacially
a move. That could even be removed, but really I don't see the reason
since it allows for a cleaner strcture definition in userland.
Don't generalize. The 4G/4G
On Fri, 29 Jun 2007, Ulrich Drepper wrote:
> On 6/29/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > [include/linux/indirect.h]
> > #define SYSIND_CTX_OPENFLAGS0
> > struct sysind_ctx_OPENFLAGS {
> > __u32 ctx;
> > __u32 flags;
>
> I agree
On Fri, 29 Jun 2007, Ulrich Drepper wrote:
On 6/29/07, Davide Libenzi [EMAIL PROTECTED] wrote:
[include/linux/indirect.h]
#define SYSIND_CTX_OPENFLAGS0
struct sysind_ctx_OPENFLAGS {
__u32 ctx;
__u32 flags;
I agree that this
On 6/30/07, Davide Libenzi [EMAIL PROTECTED] wrote:
But, a __get_user(), once you scrap off all the gcc wrapping, is bacially
a move. That could even be removed, but really I don't see the reason
since it allows for a cleaner strcture definition in userland.
Don't generalize. The 4G/4G
On Sat, 30 Jun 2007, Ulrich Drepper wrote:
On 6/30/07, Davide Libenzi [EMAIL PROTECTED] wrote:
But, a __get_user(), once you scrap off all the gcc wrapping, is bacially
a move. That could even be removed, but really I don't see the reason
since it allows for a cleaner strcture definition
On Sat, 30 Jun 2007, Davide Libenzi wrote:
Think about if we had this for the latest pselect/ppoll/epoll_pwait.
Think about how your solution and mine would apply to that very much
concrete case.
This is how all those overloaded syscalls looks like, BTW:
if (sigmask) {
On 6/29/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
[include/linux/indirect.h]
#define SYSIND_CTX_OPENFLAGS0
struct sysind_ctx_OPENFLAGS {
__u32 ctx;
__u32 flags;
I agree that this interface is more than any other in danger of
needing an
This patch-set implements the skeleton for a new sys_indirect() system call.
The reason for such system call would be to avoid the proliferation of new
system calls, introduced to only wrap old ones by setting/unsetting a given
context before/after the real system call.
The internal operation of
This patch-set implements the skeleton for a new sys_indirect() system call.
The reason for such system call would be to avoid the proliferation of new
system calls, introduced to only wrap old ones by setting/unsetting a given
context before/after the real system call.
The internal operation of
On 6/29/07, Davide Libenzi [EMAIL PROTECTED] wrote:
[include/linux/indirect.h]
#define SYSIND_CTX_OPENFLAGS0
struct sysind_ctx_OPENFLAGS {
__u32 ctx;
__u32 flags;
I agree that this interface is more than any other in danger of
needing an
24 matches
Mail list logo
