On Wed, Jan 27, 2016 at 9:36 AM, Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> 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. > In our internal version of this patch (part of the RSEQ system discussed elsewhere) we have a signed CPU id for this reason. I think it's a good idea to keep that in userspace and it makes more sense to match the user and kernel versions of the types. -- 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
