On Wed, Jan 27, 2016 at 05:36:48PM +0000, Mathieu Desnoyers wrote: > ----- 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. If getcpu_cache doesn't exist, you'll get ENOSYS. If getcpu_cache returns 0, then you can assume the kernel will give you a valid CPU number. - Josh Triplett -- 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
