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 -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
