Messages in this thread | | | From | Linus Torvalds <> | Date | Sun, 20 Jan 2013 18:39:09 -0800 | Subject | Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit |
| |
On Sun, Jan 20, 2013 at 6:30 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: > > Neither do I, to be honest. It might be saving us a few cycles on > some architectures, but I'd like to see examples of that. amd64 > doesn't seem to be one, at least...
I think that the inlining of the body should make it basically be pretty much free even on architectures that would want to do something about the casts.
.. and thinking about it, the architectures that do actually generate code for casting to a narrower type should already have selected that HAVE_SYSCALL_WRAPPERS option anyway, so the only reason *not* to select it is for a n architecture that doesn't generate any extra code.
And right now, that HAVE_SYSCALL_WRAPPERS does make it much harder to think about the header file changes.
> FWIW, there's another bit of ugliness around that area - all these > #define __SC_BLAH3, etc., all of the same form. This stuff begs for > something like > #define __MAP1(m,t,a) m(t,a) > #define __MAP2(m,t,a,...) m(t,a) __MAP1(m,__VA_ARGS__) > #define __MAP3(m,t,a,...) m(t,a) __MAP2(m,__VA_ARGS__) > #define __MAP4(m,t,a,...) m(t,a) __MAP3(m,__VA_ARGS__) > #define __MAP5(m,t,a,...) m(t,a) __MAP4(m,__VA_ARGS__) > #define __MAP6(m,t,a,...) m(t,a) __MAP5(m,__VA_ARGS__) > #define __MAP(n,...) __MAP##n(__VA_ARGS__) > with __MAP(x,__SC_DECL,__VA_ARGS__) instead of __SC_DECL##x(__VA_ARGS__) > etc. in users...
Well, I can see both sides. The above is the nice and dense declaration model with less duplication, but christ, it's hard for people to wrap their minds around unless they've seen it a million times. It really does take some getting used to, and the long-form can be easier to understand.
That said, we have so many of those things now when it comes to the syscall stuff that the dense form seems to be called for just to be consistent.
So go wild if you have the energy for it. I'm not going to pull that for 3.8, though.
Linus
| |