From: Ingo Molnar <mingo@kernel.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
anton@samba.org, Arnd Bergmann <arnd@arndb.de>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mike Travis <travis@sgi.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PULL] cpumask: finally make them variable size w/ CPUMASK_OFFSTACK.
Date: Thu, 10 May 2012 09:42:15 +0200 [thread overview]
Message-ID: <20120510074215.GA28395@gmail.com> (raw)
In-Reply-To: <87fwb8dgkn.fsf@rustcorp.com.au>
* Rusty Russell <rusty@rustcorp.com.au> wrote:
> Mainly because I didn't want to disturb the archs which don't
> care at all about large cpumasks. After all, putting a struct
> cpumask on the stack is pretty convenient.
Yes.
> But we could add a new arch config which removes it, and set
> it from x86.
Could we just use a single cpumask type, cpumask_t or so, which
would be the *only* generic method to use cpumasks?
(Current cpumask_t would move to cpumask_full_t.)
This would be the 'final' destiation for the cpumask code: the
natural type to use in new code is cpumask_t, while in special
cases we could use cpumask_full_t - but the name signals that
it's a potentially large structure.
On architectures that don't worry about large cpumasks (yet ...)
cpumask_t and cpumask_full_t maps to the same thing, so there's
no difference.
This would make things more natural IMO.
There would be no 'struct cpumask'. (and 'cpumask_var_t' would
disappear too due to the rename.)
Thoughts?
Ingo
next prev parent reply other threads:[~2012-05-10 7:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 6:10 [PULL] cpumask: finally make them variable size w/ CPUMASK_OFFSTACK Rusty Russell
2012-05-09 8:44 ` Ingo Molnar
2012-05-10 0:29 ` Rusty Russell
2012-05-10 7:42 ` Ingo Molnar [this message]
2012-05-14 3:22 ` Rusty Russell
2012-05-10 1:32 ` KOSAKI Motohiro
2012-05-10 2:16 ` Rusty Russell
2012-05-10 2:43 ` KOSAKI Motohiro
2012-05-10 4:54 ` Rusty Russell
2012-05-10 6:42 ` KOSAKI Motohiro
2012-05-14 2:58 ` Rusty Russell
2012-05-15 1:38 ` KOSAKI Motohiro
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=20120510074215.GA28395@gmail.com \
--to=mingo@kernel.org \
--cc=anton@samba.org \
--cc=arnd@arndb.de \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=travis@sgi.com \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@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.