All of lore.kernel.org
 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: Thu, 9 Mar 2017 17:31:32 -0500	[thread overview]
Message-ID: <20170309223132.GJ7825@windriver.com> (raw)
In-Reply-To: <6e336af0-792d-f0fa-face-f23007cbaca3@axentia.se>

[Re: [PATCH] mux-core: make it explicitly non-modular] On 09/03/2017 (Thu 13:01) Peter Rosin wrote:

> On 2017-03-09 10:39, Peter Rosin wrote:
> 
> *snip* *snip*
> 
> >> Per the above use case (minimal vmlinux) the unload isn't so important,
> >> and in many cases it may be racy or simply not make sense.  If that is
> >> the case, you don't need to provide a module_exit, and in the past I
> >> think we used to bump the module use count at a successful load to
> >> prevent unloading ; there might be a more elegant method now; google is
> >> your friend here.  Also, I don't think name reuse/confusion is an issue.
> > 
> > Ok, I thought it all boiled down to making the mux-core Kconfig a tristate
> > option and changing subsys_initcall(...) to module_init(...).
> > 
> > But if I do that, I cannot be sure that the mux-core has been initialized
> > before drivers and clients start to use it in the non-modular case (if
> > things are modules, the dependencies should ensure that the mux-core is
> > loaded/initialized before any users are loaded). But there is no
> > topological sorting going on for ordering init calls in the non-modular
> > case.
> > 
> > In short, I get:
> > 
> > WARNING: CPU: 0 PID: 1 at drivers/base/class.c:438: class_find_device+0xac/0xb8
> > class_find_device called for class 'mux' before it was initialized

[...]

> > 
> > So, it appears that I also have to determine if the core has been
> > initialized in all its entry points and return -EPROBE_DEFER (or something)
> > when not. I suppose I could instead initialize on-demand, but that seems
> > more difficult the do without races...
> > 
> > Am I missing something?
> 
> I did some digging and e.g. drivers/uwb was moved before drivers/usb in
> commit ae5d82cb8d60 ("uwb: build UWB before USB/WUSB") to resolve what
> appears to be a similar situation. I suppose I could just move mux up in
> drivers/Makefile so that it is before both i2c and iio.

So, you can "cheat" and leave it as subsys_initcall (and add a comment
why it is) and it will be subsys_initcall when built-in and module_init
when modular -- that should work too, and if you look around you'll
probably see many other existing instances of that going on.

init.h
   #ifndef MODULE
   [...]
   #define subsys_initcall(fn)             __define_initcall(fn, 4)

module.h
   #else /* MODULE */
   [...]
   #define subsys_initcall(fn)              module_init(fn)

Paul.
--

> 
> Cheers,
> peda
> 

      reply	other threads:[~2017-03-09 22:31 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
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 [this message]

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=20170309223132.GJ7825@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 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.