Message-ID: <4502a7e5-930f-15b6-fbef-929df29d5ef0@infradead.org>
Date:   Fri, 6 Apr 2018 18:00:09 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Lucas De Marchi <lucas.de.marchi@...il.com>
Cc:     Harish Jenny K N <harish_kandiga@...tor.com>,
        linux-modules <linux-modules@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        greg KH <gregkh@...uxfoundation.org>, jason.vas.dias@...il.com
Subject: Re: Differences between builtins and modules

On 02/24/2015 05:02 PM, Lucas De Marchi wrote:
> On Mon, Feb 23, 2015 at 12:51 PM, Michal Marek <mmarek@...e.cz> 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.
> 
> thanks for looking in detail into this.
> 
>>
>>
>>> 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.
> 
> I was actually meaning anything that can have a directory under
> /sys/module/. I figure we can't easily know this.
> 
>> Plus, there was IIRC an idea to teach lsmod to print builtin modules --
>> listing all *.o would make it rather useless.
> 
> This was one of my ideas... to traverse /sys/module and give more
> information than we actually output right now, including builtin
> modules. However, given the fact that builtin modules only have an
> entry in /sys/module if they have params and now that I'm aware of the
> race between the creation of the directory and the initstate file, I'm
> giving up on this idea for now.
> 
>>> 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.
> 
> So my current plan is to rely solely on modules.builtin to output to
> modprobe that a module is builtin. So things like "modprobe vt" will
> start to fail saying there's no vt module. Any objections here?
> 

Hi,
[sorry to resurrect such as old thread]


Would someone please answer/reply to this (related) kernel bugzilla entry:
  https://bugzilla.kernel.org/show_bug.cgi?id=118661

or I could just close it?

thanks,
-- 
~Randy

Powered by blists - more mailing lists