Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread
From: Mathieu Desnoyers <hidden>
Date: 2016-01-28 13:33:50
Also in:
lkml
----- On Jan 28, 2016, at 6:12 AM, heiko carstens heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org wrote:
On Wed, Jan 27, 2016 at 10:47:37PM +0000, Mathieu Desnoyers wrote:quoted
----- On Jan 27, 2016, at 5:11 PM, Josh Triplett josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org wrote:quoted
On Wed, Jan 27, 2016 at 09:34:35PM +0000, Mathieu Desnoyers wrote:quoted
----- On Jan 27, 2016, at 12:37 PM, Thomas Gleixner tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org wrote:quoted
On Wed, 27 Jan 2016, Thomas Gleixner wrote:quoted
On Wed, 27 Jan 2016, Mathieu Desnoyers wrote:quoted
----- On Jan 27, 2016, at 12:22 PM, Thomas Gleixner tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org wrote: Sounds fair. What is the recommended typing for "ptr" then ? uint32_t ** or uint32_t * ? It would be expected to pass a "uint32_t *" for the set operation, but the "get" operation requires a "uint32_t **".Well, you can't change the types depending on the opcode, so you need to stick with **.Alternatively you make it: (opcode, *newptr, **oldptr, flags);I'm tempted to stick to (opcode, **ptr, flags), because other syscalls that have "*newptr", "**oldptr" typically have them because they save the current state into oldptr, and set the new state, which is really not the case here. To eliminate any risk of confusion, I am tempted to keep a single "**ptr". Unless someone has a better idea...Either that or you could define it as "void *" and interpret it based on flags, but that seems unfortunate; let's not imitate ioctl-style typeless parameters. I'd stick with the double pointer and the current behavior.Allright, will do! Thanks for the feedback :)Please don't forget that you also need to implement compat handling since the size of the pointer that is being pointed to is only four bytes for compat tasks.
Oops, forgot about that. Will update my upcoming v3 to handle this properly. Well spotted ! Thanks! Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com