linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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");
> > 
> 

  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).