On 05/17/2012 03:32 PM, Linus Torvalds wrote: > > The whole __kernel_ prefix was a mistake, but it at least makes sense > for certain things where it is really about some random kernel choice > (ie __kernel_pid_t). Even there I despise it, because it's not really > about "kernel choice", it's about just the real native type for uid_t > - the fact that user-mode then occasionally screwed up because glibc > has chosen crazy extended types is really not a "kernel" issue at all. > So the naming in general is painful. > > When it comes to the x32 thing I think it's *doubly* wrong, because > this isn't even about a "kernel choice". It's damn well the native > machine word-size. The fact that a limited user-mode ABI then limits > "long" to 32-bit is not the kernels problem. > > So I'd really like to see some discussion about naming. What does this > have to do with "kernel"? Nothing. It's the native word-size of the > machine, for crying out loud. The fact that some user interfaces may > limit themselves is not a "user mode vs kernel" thing. It also puts a clear line between the kernel and user space namespaces, which has been an ongoing problem (we *still* haven't cleaned out some namespace pollution in the i386 <asm/signal.h> for example.) That being said, this is a lot like the __u* and __s* types which we use instead of <stdint.h> for similar reasons. I don't know if __ulong/__slong or __uword/__sword would be better here? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
