----- On Jan 27, 2016, at 12:24 PM, Thomas Gleixner tglx@xxxxxxxxxxxxx wrote: > On Wed, 27 Jan 2016, Josh Triplett wrote: >> With the dynamic allocation removed, this seems sensible to me. One >> minor nit: s/int32_t/uint32_t/g, since a location intended to hold a CPU >> number should never need to hold a negative number. > > You try to block the future of computing: https://lwn.net/Articles/638673/ Besides impossible architectures, there is actually a use-case for signedness here. It makes it possible to initialize the cpu number cache to a negative value, e.g. -1, in userspace. Then, a check for value < 0 can be used to figure out cases where the getcpu_cache system call is not implemented, and where a fallback (vdso or getcpu syscall) needs to be used. This is why I have chosen a signed type for the cpu cache so far. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
