Re: [patch 0/6] sys_indirect RFC - sys_indirect introduction

[Davide Libenzi <davidel@xmailserver.org>]

On Sat, 30 Jun 2007, Ulrich Drepper wrote:

> On 6/30/07, Davide Libenzi <davidel@xmailserver.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/