linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.de.marchi@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Harish Jenny K N <harish_kandiga@mentor.com>,
	linux-modules <linux-modules@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	greg KH <gregkh@linuxfoundation.org>,
	Michal Marek <mmarek@suse.cz>
Subject: Differences between builtins and modules
Date: Mon, 23 Feb 2015 11:30:58 -0300	[thread overview]
Message-ID: <CAKi4VA+1krn9rdBWE69DkhNZSrxJoeYzyPgvn-SUk8U0=CxFkw@mail.gmail.com> (raw)

Changing the subject because this is unrelated to the patch to kmod. It was:
[PATCH] libkmod-module: Remove directory existence check for KMOD_MODULE_BUILTIN

CC'ing Michael Marek who created the modules.builtin file a while ago.

On Thu, Feb 19, 2015 at 12:25 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Rusty, thinking again if we fallback to "coming" instead of "builtin"
>> everything should be fine, no? Because the decision about builtin has
>> already been taken by looking at the modules.builtin index. If we
>> return "coming" here the second call to modprobe would call
>> init_module() again which would wait for the first one to complete (or
>> return EEXIST if it's already live) since we only shortcut the
>> init_module() call if the module is live or builtin
>
> It's weird that your code should care about this at all.  Ideally,
> userspace would see builtin modules as simply unremovable ones.
> Historically, it hasn't; it was only module parameters for builtins
> which caused us to expose built modules.

While integrating the patch above in kmod I noticed there are more differences.

/sys/module/<modname>/ may exist and modname not be present in
modules.builtin index. Looking in the kernel tree, this is because
Makefile.modbuiltin adds only those that can be tristate and not those
that can be only boolean. It may make sense because since a "module"
can never be compiled as a "module", there would be no reason to put
it in the index.

right now in kmod if we do this:

"modprobe --show-depends vt" it reports as "builtin" since there is a
directory in /sys/module

However if vt had no arguments, it would have been reported as "not found".

This could be particularly bad if in a kernel version an option was
tristate and in a new version it changed to boolean. I'm not sure if
this is common to happen in kernel. Any code that did "modprobe
<module>" would start to fail.

My questions are:
1) should we put *all* the "modules" in the builtin index?
2) should we actually check /sys/module/<modulename> to report a
module as builtin or just stop doing that and rely solely in the
index? Initially I'd like to do the opposite, but given the race in
deciding this I'm favoring the index.

thanks

-- 
Lucas De Marchi

             reply	other threads:[~2015-02-23 14:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-23 14:30 Lucas De Marchi [this message]
2015-02-23 15:51 ` Differences between builtins and modules Michal Marek
2015-02-24 11:42   ` Harish Jenny Kandiga Nagaraj
2015-02-25  1:07     ` Lucas De Marchi
2015-02-25  1:02   ` Lucas De Marchi
2015-02-25 11:53     ` Michal Marek
2015-02-28 17:24       ` Lucas De Marchi
2018-04-07  1:00     ` Randy Dunlap
2018-05-10 12:03       ` Jason Vas Dias

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='CAKi4VA+1krn9rdBWE69DkhNZSrxJoeYzyPgvn-SUk8U0=CxFkw@mail.gmail.com' \
    --to=lucas.de.marchi@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=harish_kandiga@mentor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=rusty@rustcorp.com.au \
    /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).