[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0706301458300.2957@alien.or.mcafeemobile.com>
Date: Sat, 30 Jun 2007 15:27:58 -0700 (PDT)
From: Davide Libenzi <davidel@...ilserver.org>
To: Ulrich Drepper <drepper@...il.com>
cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 0/6] sys_indirect RFC - sys_indirect introduction
On Sat, 30 Jun 2007, Ulrich Drepper wrote:
> On 6/30/07, Davide Libenzi <davidel@...ilserver.org> 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 kernel, for instance, doesn't have this
> property. Who knows what else will come up. Anyway, two memcpy are
> slower than one.
>
> > But this does not allow more than one context to be set at a time, like
> > the current implementation does. Ie, the current implementation allow you
> > to:
>
> Of course it does. It just requires an appropriate union element.
> I've listed flags and sigset_t as separate union elements since I
> cannot think of a place where we need both extensions. Should there
> be one this can easily be changed.
Why do you want to stick everything inside a structure, with nested
strctures and unions, when they clearly are separate contexts?
Also, unions don't work if you want to pass multiple contexts at a time.
You need your structure to contains *all* the possible contexts.
You do not want to sell the monster-struct-union by branding an extra
__get_user(), do you?
On top of that, the single pointer to the compat multi-context strcture,
will force the kernel to decide which one of the members is actually valid
or not. The set/unset callbacks separate each context from a structure POV
and from a setup/teardown POV, and allow the kernel to use their native
data structures. 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.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists