From: Andi Kleen <andi@firstfloor.org>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: Andi Kleen <andi@firstfloor.org>,
Johannes Berg <johannes@sipsolutions.net>,
"backports@vger.kernel.org" <backports@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Yann E. MORIN" <yann.morin.1998@free.fr>,
Michal Marek <mmarek@suse.cz>,
Stefan Assmann <sassmann@kpanic.de>
Subject: Re: [PATCH v2 03/13] backports: allow for different backport prefix
Date: Thu, 6 Nov 2014 00:31:40 +0100 [thread overview]
Message-ID: <20141105233140.GE12538@two.firstfloor.org> (raw)
In-Reply-To: <CAB=NE6Wu7gFh+_1ebiaWCq2cUt_SnCMB-+1Xv9ZuZtBafdg0Vg@mail.gmail.com>
> The only thing that was not clear to me from reviewing the module
> namespace stuff a while ago was the original intent, but I confess I
> actually only looked at the technical details to see if it was
> applicable to the backports case, do you recall the original
> motivation ?
The original intent was to provide a cleaner export symbol API.
There are roughly two classes of exported symbols:
- Generally usable, well designed, interfaces intended to be used by multiple
modules (e.g. functions for drivers to register themselves or
library functions)
- Special purpose exports that are only really for a single
module, but are not intended as a general interface. These interfaces
are usually not really clean and reusable.
The idea was to mark the later special purpose exports with the name of the
module that is supposed to them. They wouldn't be available
to everybody else and wouldn't become part of the general
kernel module API.
-Andi
next prev parent reply other threads:[~2014-11-05 23:31 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 3:18 [PATCH v2 00/13] backports: add kernel integration support Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 01/13] backports: move legacy and SmPL patch application into helper Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 02/13] backports: ifdef around module_init() module_exit() for modules Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 03/13] backports: allow for different backport prefix Luis R. Rodriguez
2014-11-05 7:46 ` Johannes Berg
2014-11-05 9:16 ` Luis R. Rodriguez
2014-11-05 9:22 ` Johannes Berg
2014-11-05 19:42 ` Luis R. Rodriguez
2014-11-05 21:17 ` Johannes Berg
2014-11-05 22:21 ` Luis R. Rodriguez
2014-11-05 23:09 ` Andi Kleen
2014-11-05 23:15 ` Luis R. Rodriguez
2014-11-05 23:31 ` Andi Kleen [this message]
2014-11-05 3:18 ` [PATCH v2 04/13] backports: replace BACKPORT_PWD with BACKPORT_DIR Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 05/13] backports: use BACKPORT_DIR prefix on kconfig sources Luis R. Rodriguez
2014-11-05 7:51 ` Johannes Berg
2014-11-05 20:11 ` Luis R. Rodriguez
2014-11-05 21:19 ` Johannes Berg
2014-11-05 22:22 ` Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 06/13] backports: update dependencies map file Luis R. Rodriguez
2014-11-05 7:54 ` Johannes Berg
2014-11-05 20:13 ` Luis R. Rodriguez
2014-11-05 21:20 ` Johannes Berg
2014-11-05 22:23 ` Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 07/13] backports: split Kconfig into Kconfig.package and Kconfig.sources Luis R. Rodriguez
2014-11-05 7:55 ` Johannes Berg
2014-11-05 20:14 ` Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 08/13] backports: move version file generation to run earlier Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 09/13] backports: define C code backport version info using CPTCFG_ Luis R. Rodriguez
2014-11-05 7:57 ` Johannes Berg
2014-11-05 20:29 ` Luis R. Rodriguez
2014-11-05 21:20 ` Johannes Berg
2014-11-05 22:27 ` Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 10/13] backports: add backport version parsing for kernel integration Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 11/13] backports: prefix c-file / h-file auto backport with BPAUTO Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 12/13] backports: remove extra BACKPORT_ prefix from kernel versioning Luis R. Rodriguez
2014-11-05 3:18 ` [PATCH v2 13/13] backports: add full kernel integration support Luis R. Rodriguez
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=20141105233140.GE12538@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=backports@vger.kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=mmarek@suse.cz \
--cc=sassmann@kpanic.de \
--cc=yann.morin.1998@free.fr \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox