From: Paul Jackson <pj@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Simon.Derr@bull.net, linux-kernel@vger.kernel.org, ak@suse.de,
torvalds@osdl.org, clameter@sgi.com
Subject: Re: [PATCH 01/02] cpuset bitmap and mask remap operators
Date: Mon, 24 Oct 2005 01:16:13 -0700 [thread overview]
Message-ID: <20051024011613.691e28f4.pj@sgi.com> (raw)
In-Reply-To: <20051024004833.50d9676b.akpm@osdl.org>
Andrew wrote:
> > +#define node_remap(oldbit, old, new) \
> > + __node_remap((oldbit), &(old), &(new), MAX_NUMNODES)
> > +static inline int __node_remap(int oldbit, ...
>
> What's the reason for the wrapper macro?
Most all the nodemask/cpumask operators are like that. It allows
writing *mask code as if masks were pass by value (which is how the
vast majority of kernel hackers, working on systems with one-word
masks, think of them), while actually passing by reference, to
avoid unnecessary stack copies of multiword masks.
> +EXPORT_SYMBOL(bitmap_bitremap);
>
> Is that deliberately not EXPORT_SYMBOL_GPL?
It's not deliberate that I am aware of.
But it does seem to be the common practice ....
All the bitmap routines are that way - no GPL. In fact it seems that
almost all the EXPORT_SYMBOLS in the lib/*.c routines are that way - 12
with GPL and 174 without GPL, or some such. The only lib/*.c GPL
exports are in lib/klist.c and lib/kobject_uevent.c.
Is this bad?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2005-10-24 8:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-24 7:27 [PATCH 01/02] cpuset bitmap and mask remap operators Paul Jackson
2005-10-24 7:27 ` [PATCH 02/02] cpuset automatic numa mempolicy rebinding Paul Jackson
2005-10-24 8:36 ` Dave Hansen
2005-10-24 14:47 ` Paul Jackson
2005-10-24 14:52 ` Dave Hansen
2005-10-24 15:02 ` Paul Jackson
2005-10-24 7:48 ` [PATCH 01/02] cpuset bitmap and mask remap operators Andrew Morton
2005-10-24 8:16 ` Paul Jackson [this message]
2005-10-24 8:37 ` Andrew Morton
2005-10-24 14:37 ` Paul Jackson
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=20051024011613.691e28f4.pj@sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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.