Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752615AbbB1RYs (ORCPT ); Sat, 28 Feb 2015 12:24:48 -0500 Received: from mail-oi0-f42.google.com ([209.85.218.42]:37064 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751105AbbB1RYr (ORCPT ); Sat, 28 Feb 2015 12:24:47 -0500 MIME-Version: 1.0 In-Reply-To: <20150225115336.GA31354@sepie.suse.cz> References: <54EB4C83.2000500@suse.cz> <20150225115336.GA31354@sepie.suse.cz> From: Lucas De Marchi Date: Sat, 28 Feb 2015 14:24:26 -0300 Message-ID: Subject: Re: Differences between builtins and modules To: Michal Marek Cc: Rusty Russell , Harish Jenny K N , linux-modules , lkml , greg KH Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3751 Lines: 81 On Wed, Feb 25, 2015 at 8:53 AM, Michal Marek wrote: > On Tue, Feb 24, 2015 at 10:02:55PM -0300, Lucas De Marchi wrote: >> On Mon, Feb 23, 2015 at 12:51 PM, Michal Marek wrote: >> > On 2015-02-23 15:30, Lucas De Marchi wrote: >> >> 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. > > I see. Well, we could generate the .modinfo section also for builtin > object files and discard it from vmlinux later, like this: > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > index ac78910..efe1798 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -683,6 +683,7 @@ > EXIT_CALL \ > *(.discard) \ > *(.discard.*) \ > + *(.modinfo) \ > } > > /** > diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h > index 1c9effa..f38abfa 100644 > --- a/include/linux/moduleparam.h > +++ b/include/linux/moduleparam.h > @@ -16,23 +16,17 @@ > /* Chosen so that structs with an unsigned long line up. */ > #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long)) > > -#ifdef MODULE > #define __MODULE_INFO(tag, name, info) \ > static const char __UNIQUE_ID(name)[] \ > __used __attribute__((section(".modinfo"), unused, aligned(1))) \ > = __stringify(tag) "=" info > -#else /* !MODULE */ > -/* This struct is here for syntactic coherency, it is not used */ > -#define __MODULE_INFO(tag, name, info) \ > - struct __UNIQUE_ID(name) {} > -#endif > #define __MODULE_PARM_TYPE(name, _type) \ > - __MODULE_INFO(parmtype, name##type, #name ":" _type) > + __MODULE_INFO(parmtype, name##type, MODULE_PARAM_PREFIX #name ":" _type) > > /* One for each parameter, describing how to use it. Some files do > multiple of these per line, so can't just use MODULE_INFO. */ > #define MODULE_PARM_DESC(_parm, desc) \ > - __MODULE_INFO(parm, _parm, #_parm ":" desc) > + __MODULE_INFO(parm, _parm, MODULE_PARAM_PREFIX #_parm ":" desc) > > struct kernel_param; > > Then some script would look at the parmtype= fields in the built-in.o > files and complement the list of builtin modules. However, the question > is whether this is worth it. As far as I understand, the problem is just > the discrepancy between modules.builtin and /sys/module. In practice, no > sane tool is going to need to modprobe 'vt' or 'printk', because there > is no configuration in which these modules would exist. Indeed, not sure it's worth it. I did the change in kmod so we don't check /sys/module anymore [1]. If this is problematic for distros then maybe we add a patch like yours to the kernel so they are also present in modules.builtin index. thanks -- Lucas De Marchi [1] https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/?id=fd44a98ae2eb5eb32161088954ab21e58e19dfc4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/