From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Peter Rosin <peda@axentia.se>
Cc: <linux-kernel@vger.kernel.org>, Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH] mux-core: make it explicitly non-modular
Date: Wed, 8 Mar 2017 09:38:47 -0500 [thread overview]
Message-ID: <20170308143847.GA22171@windriver.com> (raw)
In-Reply-To: <05d65cbe-340a-740c-6cb3-2c63d21ea4d9@axentia.se>
[Re: [PATCH] mux-core: make it explicitly non-modular] On 08/03/2017 (Wed 10:38) Peter Rosin wrote:
> On 2017-03-07 23:41, Paul Gortmaker wrote:
> > The Kconfig currently controlling compilation of this code is:
> >
> > drivers/mux/Kconfig:menuconfig MULTIPLEXER
> > drivers/mux/Kconfig: bool "Multiplexer subsystem"
> >
> > ...meaning that it currently is not being built as a module by anyone.
> >
> > Lets remove the couple traces of modular infrastructure use, so that
> > when reading the driver there is no doubt it is builtin-only.
> >
> > Hence we delete the MODULE_LICENSE tag etc. since all that information
> > is already contained at the top of the file in the comments.
>
> Hi Paul,
>
> Yup, it is confirmed, I don't really know what I'm doing. In particular
> when in comes to modules... I did wonder about this when I wrote the
> code and one specific thing I wondered about was how module loading is
> triggered.
>
> I can imagine that calling a function that happens to be exported from
> a module triggers its loading and that failure to load the module leads
> to an oops. But I don't know if that is even remotely correct? Is it?
No, that would be pretty user unfriendly. When you "insmod" a module,
the kernel checks just like a linker, that all the functions it wants to
use are available. If they are not, then the kernel fails to load it.
But it fails gracefully with a list of the unresolved symbols.
Obviously managing all the module interdependencies manually would be
tedious, so that is what what "depmod" does. Then loading of a module
is usually done with "modprobe", which will consult the depmod data and
then "insmod" the required modules in the needed order.
> Is there a short answer? Or what should I read for a longer one?
Well, now that you know it won't oops from a module needing a module,
perhaps you do now want to make the core support modular? If I look in
my ARM build, I see:
paul@yow-lpgnfs-02:~/git/arm-build/drivers/mux$ ls -l
total 96
-rw-rw-r-- 1 paul paul 399 Mar 7 16:41 built-in.mod.c
-rw-rw-r-- 1 paul paul 15999 Mar 7 16:41 built-in.o
-rw-rw-r-- 1 paul paul 0 Mar 7 16:12 modules.builtin
-rw-rw-r-- 1 paul paul 65 Mar 7 16:41 modules.order
-rw-rw-r-- 1 paul paul 8324 Mar 7 16:49 mux-adg792a.ko
-rw-rw-r-- 1 paul paul 1566 Mar 7 16:46 mux-adg792a.mod.c
-rw-rw-r-- 1 paul paul 3552 Mar 7 16:47 mux-adg792a.mod.o
-rw-rw-r-- 1 paul paul 6824 Mar 7 16:41 mux-adg792a.o
-rw-rw-r-- 1 paul paul 20472 Mar 7 16:41 mux-core.o
-rw-rw-r-- 1 paul paul 7680 Mar 7 16:49 mux-gpio.ko
-rw-rw-r-- 1 paul paul 1550 Mar 7 16:46 mux-gpio.mod.c
-rw-rw-r-- 1 paul paul 3408 Mar 7 16:47 mux-gpio.mod.o
-rw-rw-r-- 1 paul paul 6360 Mar 7 16:41 mux-gpio.o
paul@yow-lpgnfs-02:~/git/arm-build/drivers/mux$
Note that mux-core doesn't have a .ko (modular variant) and also you can
confirm with nm that everything in mux-core.o is in built-in.o (in this
case the nm outputs are virtually identical).
But if you do make that a module too, you will need the MODULE_LICENSE
tag. The kernel also checks that license compatibility is maintained ;
i.e. a proprietary module can't use functions from another module doing
EXPORT_SYMBOL_GPL.
> Anyway, I'll add this to the queue, and fold it if I happen to rebase.
Oh, and speaking of EXPORT_SYMBOL, I should have added <linux/export.h>
to your file with the patch I sent, since it does do exports.
Hope that helps,
Paul.
--
> Thanks!
>
> Cheers,
> peda
>
> > Cc: Peter Rosin <peda@axentia.se>
> > Cc: Jonathan Cameron <jic23@kernel.org>
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> > ---
> >
> > [feel free to fold this change into the original addition commit if
> > you happen to be rebasing for some other reason... ]
> >
> > drivers/mux/mux-core.c | 6 +-----
> > 1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
> > index 46088a0f9677..7b4af6370e37 100644
> > --- a/drivers/mux/mux-core.c
> > +++ b/drivers/mux/mux-core.c
> > @@ -15,7 +15,7 @@
> > #include <linux/device.h>
> > #include <linux/err.h>
> > #include <linux/idr.h>
> > -#include <linux/module.h>
> > +#include <linux/init.h>
> > #include <linux/mux.h>
> > #include <linux/of.h>
> > #include <linux/of_platform.h>
> > @@ -408,7 +408,3 @@ void devm_mux_control_put(struct device *dev, struct mux_control *mux)
> > EXPORT_SYMBOL_GPL(devm_mux_control_put);
> >
> > subsys_initcall(mux_init);
> > -
> > -MODULE_DESCRIPTION("Multiplexer subsystem");
> > -MODULE_AUTHOR("Peter Rosin <peda@axentia.se");
> > -MODULE_LICENSE("GPL v2");
> >
>
next prev parent reply other threads:[~2017-03-08 14:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-07 22:41 [PATCH] mux-core: make it explicitly non-modular Paul Gortmaker
2017-03-08 9:38 ` Peter Rosin
2017-03-08 14:38 ` Paul Gortmaker [this message]
2017-03-08 15:32 ` Peter Rosin
2017-03-09 0:32 ` Paul Gortmaker
2017-03-09 9:39 ` Peter Rosin
2017-03-09 12:01 ` Peter Rosin
2017-03-09 22:31 ` Paul Gortmaker
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=20170308143847.GA22171@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=jic23@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
/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;
as well as URLs for NNTP newsgroup(s).