Message-ID: <54EC638E.1060007@mentor.com>
Date:	Tue, 24 Feb 2015 17:12:06 +0530
From:	Harish Jenny Kandiga Nagaraj <harish_kandiga@...tor.com>
To:	Michal Marek <mmarek@...e.cz>,
	Lucas De Marchi <lucas.de.marchi@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>
CC:	linux-modules <linux-modules@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	greg KH <gregkh@...uxfoundation.org>
Subject: Re: Differences between builtins and modules


On Monday 23 February 2015 09:21 PM, Michal Marek wrote:
> On 2015-02-23 15:30, Lucas De Marchi wrote:
>> 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.
> I think it's quite uncommon (*) and also the use case for loading
> builtin modules is not that common. I can think of:
> 1) building the initramfs, to determine which *.ko files need to be
>    copied to it. Since such tools are often updated for other reasons,
>    it's not a big deal.
> 2) Hardcoded module names in things like softdep -- hopefully not that
>    common either, plus the kernel-provided soft dependencies can be
>    fixed together with the change.
>
> Until not so long ago, the kernel would return EINVAL if passed a
> non-existent (renamed, removed) module option to init_module, yet there
> were no attempts at preserving the module options for compatibility reasons.
>
> (*) I now did a quick search:
> $ git log -p origin/master --no-merges -- '*/Kconfig*' | grep -C3 '^-
> *tristate' | grep '^+ *bool'
> +       bool "Intel P state control"
> +       bool "Intel microcode patch loading support"
> +       bool "AMD microcode patch loading support"
> +        bool "STI text console"
> +       bool "Enable DDC2 Support"
> +       bool "Enable Console Acceleration"
>
> That's only 6 cases in the whole git history. Maybe there are a few more
> hidden outside the three-line context as part of larger edits, but I'm
> sure more modules have been *removed* entirely from the kernel over this
> period.
>
>
>> My questions are:
>> 1) should we put *all* the "modules" in the builtin index?
> You mean all *.o files that do not end up in some *.ko? That won't work,
> because unlike module names, the names of object files are not global.
> Plus, there was IIRC an idea to teach lsmod to print builtin modules --
> listing all *.o would make it rather useless.
>
>
>> 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.
> If the race between the creation of /sys/module/<modulename> and
> /sys/module/<modulename>/initstate is inevitable, then I'm afraid we
> have to rely on the index.
>
> Michal

Can we add some flag like
KMOD_PROBE_FORCE_DIRECTORY_CHECK = 0x00040,
and pass it to kmod_module_get_initstate to make
"modprobe --show-depends vt" to report as "builtin" ?

Also if the use case for loading builtin modules is not that common
( Also don’t know if 'modprobe vt' command does the loading if not loaded)
can we have the same flags be used after checking if it is  .ko file or from .o file if required?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists