Messages in this thread | | | Date | Sat, 30 Jun 2007 15:27:58 -0700 (PDT) | From | Davide Libenzi <> | 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@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/
| |