On Tue, 4 Aug 2015 16:33:44 +0200
Borislav Petkov wrote:
> Hell, we can drop that "key" or "branch" from the whole API for all I
> know. "static_" is enough for me to say what the thing is. But that's
> just me - I like short names - no poems in code and sh*t.
>
> Thoughts, comments?
I agree to
On Tue, Aug 4, 2015 at 7:33 AM, Borislav Petkov wrote:
> On Tue, Aug 04, 2015 at 08:06:45AM -0400, Steven Rostedt wrote:
>> I just don't like the inconsistency of the initialization and the
>> setting.
>>
>> Either have:
>>
>> DEFINE_STATIC_KEY_TRUE()
>> DEFINE_STATIC_KEY_FALSE()
>>
>> and
>>
>>
On Tue, Aug 04, 2015 at 08:06:45AM -0400, Steven Rostedt wrote:
> I just don't like the inconsistency of the initialization and the
> setting.
>
> Either have:
>
> DEFINE_STATIC_KEY_TRUE()
> DEFINE_STATIC_KEY_FALSE()
>
> and
>
> static_branch_set_true()
> static_branch_set_false()
>
>
> o
On Tue, 4 Aug 2015 05:37:33 +0200
Borislav Petkov wrote:
> On Mon, Aug 03, 2015 at 05:57:57PM -0400, Steven Rostedt wrote:
> > That's implementation details, not a general concept that users will
> > need to know about.
>
> Why?
>
> It is a branch, regardless of which insn is used on which arch
On Tue, Aug 04, 2015 at 02:50:32PM +0800, yalin wang wrote:
> is this means static_key_{true,false}() are deprecated ?
Yes.
> do you need mark static_key_{true,false}() as deprecated?
> like this:
> static __always_inline __deprecated bool static_key_false(struct static_key
> *key) ?
Not unti
> On Jul 28, 2015, at 21:21, Peter Zijlstra wrote:
>
> There are various problems and short-comings with the current
> static_key interface:
>
> - static_key_{true,false}() read like a branch depending on the key
> value, instead of the actual likely/unlikely branch depending on
> init valu
On Mon, Aug 03, 2015 at 09:07:53PM -0700, Andy Lutomirski wrote:
> Except that, with the new interface, static_key_likely is the other
> way around, right? If the key is true (i.e. enabled), then it doesn't
> branch.
>
> I think of the key as a boolean thing that happens to work by code
> patchin
On Mon, Aug 3, 2015 at 8:37 PM, Borislav Petkov wrote:
> On Mon, Aug 03, 2015 at 05:57:57PM -0400, Steven Rostedt wrote:
>> That's implementation details, not a general concept that users will
>> need to know about.
>
> Why?
>
> It is a branch, regardless of which insn is used on which arch - it i
On Mon, Aug 03, 2015 at 05:57:57PM -0400, Steven Rostedt wrote:
> That's implementation details, not a general concept that users will
> need to know about.
Why?
It is a branch, regardless of which insn is used on which arch - it is
either active and you *branch* to that code or *inactive* and yo
On Mon, 3 Aug 2015 22:00:02 +0200
Peter Zijlstra wrote:
> On Mon, Aug 03, 2015 at 03:28:10PM -0400, Steven Rostedt wrote:
> > Technically, one can think: "activate the branch", but we are
> > activating not the branch, but the jump label itself.
>
> No you are enabling the branch, you're making
On Mon, Aug 03, 2015 at 03:28:10PM -0400, Steven Rostedt wrote:
> Technically, one can think: "activate the branch", but we are
> activating not the branch, but the jump label itself.
No you are enabling the branch, you're making the branch body active.
There is no enable/disable/true/false for t
On Mon, 3 Aug 2015 21:18:16 +0200
Peter Zijlstra wrote:
> On Mon, Aug 03, 2015 at 03:03:59PM -0400, Steven Rostedt wrote:
>
> > I wonder if static_branch_set_false(&blah) would be a better name to
> > understand. What does "disable" / "enable" mean?
>
> "make false" / "make true" ? Check a loca
On Mon, Aug 03, 2015 at 03:03:59PM -0400, Steven Rostedt wrote:
> I wonder if static_branch_set_false(&blah) would be a better name to
> understand. What does "disable" / "enable" mean?
"make false" / "make true" ? Check a local dictionary.
http://lmgtfy.com/?q=enable
"2. computing: make (a dev
On Wed, 29 Jul 2015 10:49:06 +0200
Peter Zijlstra wrote:
> On Wed, Jul 29, 2015 at 09:19:22AM +0200, Vlastimil Babka wrote:
>
> > How would one define a static key that's e.g. expected to be mostly false,
> > but
> > with initial value of true, e.g. during boot?
>
> DEFINE_STATIC_KEY_TRUE(blah
On Tue, 2015-07-28 at 15:21 +0200, Peter Zijlstra wrote:
> There are various problems and short-comings with the current
> static_key interface:
...
> ---
> arch/powerpc/include/asm/jump_label.h | 19
This looks sane and seems to be working, so powerpc bits:
Acked-by: Michael Ellerman
c
On Wed, Jul 29, 2015 at 09:19:22AM +0200, Vlastimil Babka wrote:
> How would one define a static key that's e.g. expected to be mostly false, but
> with initial value of true, e.g. during boot?
DEFINE_STATIC_KEY_TRUE(blah);
will get you the true at boot time.
You'll then want to use:
i
On 07/28/2015 03:21 PM, Peter Zijlstra wrote:
> +/*
> -- */
> +
> +/*
> + * Two type wrappers around static_key, such that we can use compile time
> + * type differentiation to emit the right code.
> + *
> + * All the below co
On Tue, Jul 28, 2015 at 03:21:01PM +0200, Peter Zijlstra wrote:
> There are various problems and short-comings with the current
> static_key interface:
>
> - static_key_{true,false}() read like a branch depending on the key
>value, instead of the actual likely/unlikely branch depending on
>
On Tue, Jul 28, 2015 at 07:00:55PM +0200, Rabin Vincent wrote:
>
> This is missing an include of asm/unified.h for the WASM():
>
> diff --git a/arch/arm/include/asm/jump_label.h
> b/arch/arm/include/asm/jump_label.h
> index f8bc12f..34f7b69 100644
> --- a/arch/arm/include/asm/jump_label.h
> +++
On Tue, Jul 28, 2015 at 03:21:01PM +0200, Peter Zijlstra wrote:
> --- a/arch/arm/include/asm/jump_label.h
> +++ b/arch/arm/include/asm/jump_label.h
> @@ -7,20 +7,28 @@
>
> #define JUMP_LABEL_NOP_SIZE 4
>
> -#ifdef CONFIG_THUMB2_KERNEL
> -#define JUMP_LABEL_NOP "nop.w"
> -#else
> -#define
There are various problems and short-comings with the current
static_key interface:
- static_key_{true,false}() read like a branch depending on the key
value, instead of the actual likely/unlikely branch depending on
init value.
- static_key_{true,false}() are, as stated above, tied to th
21 matches
Mail list logo
