Messages in this thread | | | Date | Thu, 17 May 2012 15:41:54 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 01/10] Use __kernel_long_t in struct timex |
| |
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.
| |