All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Jason Baron <jbaron@akamai.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: static key arrays?
Date: Fri, 11 Sep 2015 13:10:03 +0200	[thread overview]
Message-ID: <20150911111003.GK18489@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1441964735.2083.4.camel@sipsolutions.net>

On Fri, Sep 11, 2015 at 11:45:35AM +0200, Johannes Berg wrote:
> Hi Peter, Jason, all,
> 
> Per the recent type-safe API changes, it's no longer easy to generate
> an array of static keys. I was planning to do that for a set of very
> unlikely debug options.
> 
> It sounds like you're planning to remove the previous API entirely at
> some point, so I'm wondering if you've given any thought to this
> possibility.

If possible I'd kill static_key_{true,false}() and
static_key_slow_{inc,dec}. Not sure how much more makes sense, the new
interface builds on parts of the old stuff.

> I briefly played with the idea of adding a macro for that, but the
> necessary "REPEAT(n, d)" macro for the initialisation becomes ugly
> pretty quickly and, afaict, needs to have enough macros for the maximum
> expected numbers.
> 
> For the case I was looking at it's static_key_false so a zero
> -initialized array would be sufficient, but that can't be done easily
> with a static_key_true.

As long as its all the same type it shouldn't be too hard;

struct static_key_false array[n] = { STATIC_KEY_FALSE_INIT, };

or something like that.

The scheduler has an array of these things that has different types;
which if going to be even more interesting. I'm not quite sure what to
do there, but I think it'll end up relying on the fact that both types
share the same base (struct static_key) and involve a lot of type
casting :-)


  reply	other threads:[~2015-09-11 11:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11  9:45 static key arrays? Johannes Berg
2015-09-11 11:10 ` Peter Zijlstra [this message]
2015-09-11 12:14   ` Johannes Berg
2015-09-11 14:41     ` Rasmus Villemoes
2015-09-11 14:55       ` Johannes Berg
2015-09-11 11:17 ` Baron, Jason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150911111003.GK18489@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=jbaron@akamai.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.