[PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Kirill Tkhai]

This series implements a possibility to show the list of built-in drivers
to userspace. The names of drivers will be the same as when they are modules.
So, if your system has "loop" driver then it appears either in /proc/modules
or in /proc/built-in and userspace will be able to know about this.

Now this is impossible. The only way to get kernel configuration is
/proc/config.gz, but CONFIG_* names can change from time to time. Module
names are more or less standardized.

---

Kirill Tkhai (3):
      kbuild: Make targets names tree-wide unique on x86
      core: Save list of built-in drivers names
      core: create /proc/built-in file to show the list of built-in drivers


 drivers/acpi/acpica/Makefile      |   28 +++++++--------
 drivers/pnp/pnpacpi/Makefile      |    4 +-
 fs/proc/Makefile                  |    1 +
 fs/proc/builtin.c                 |   70 +++++++++++++++++++++++++++++++++++++
 include/asm-generic/vmlinux.lds.h |    3 ++
 init/Makefile                     |   19 ++++++----
 scripts/Makefile.build            |   14 +++++--
 7 files changed, 112 insertions(+), 27 deletions(-)
 create mode 100644 fs/proc/builtin.c

--
Signed-off-by: Kirill Tkhai <kthai@parallels.com>

[PATCH 1/3] kbuild: Make targets names tree-wide unique on x86

[Kirill Tkhai]

These are the duplicate targets names found on x86 allyesconfig.

Change "acpi" on "acpica" in drivers/acpi/acpica/Makefile.

Change "pnp" on "pnpacpi" in drivers/pnp/pnpacpi/Makefile.

Also remove "mounts" target from init/Makefile. It's artificial
driver name, let's do not litter namespace.

Signed-off-by: Kirill Tkhai <ktkhai@parallels.com>
---
 drivers/acpi/acpica/Makefile |   28 ++++++++++++++--------------
 drivers/pnp/pnpacpi/Makefile |    4 ++--
 init/Makefile                |   19 ++++++++++++-------
 3 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index c1a9635..c425735 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -5,10 +5,10 @@
 ccflags-y			:= -Os -DBUILDING_ACPICA
 ccflags-$(CONFIG_ACPI_DEBUG)	+= -DACPI_DEBUG_OUTPUT
 
-# use acpi.o to put all files here into acpi.o modparam namespace
-obj-y	+= acpi.o
+# use acpica.o to put all files here into acpica.o modparam namespace
+obj-y	+= acpica.o
 
-acpi-y :=		\
+acpica-y :=		\
 	dsargs.o	\
 	dscontrol.o	\
 	dsfield.o	\
@@ -24,7 +24,7 @@ acpi-y :=		\
 	dswscope.o	\
 	dswstate.o
 
-acpi-y +=		\
+acpica-y +=		\
 	evevent.o	\
 	evgpe.o		\
 	evgpeblk.o	\
@@ -41,7 +41,7 @@ acpi-y +=		\
 	evxfgpe.o	\
 	evxfregn.o
 
-acpi-y +=		\
+acpica-y +=		\
 	exconfig.o	\
 	exconvrt.o	\
 	excreate.o	\
@@ -67,7 +67,7 @@ acpi-y +=		\
 	exsystem.o	\
 	exutils.o
 
-acpi-y +=		\
+acpica-y +=		\
 	hwacpi.o	\
 	hwesleep.o	\
 	hwgpe.o		\
@@ -78,9 +78,9 @@ acpi-y +=		\
 	hwxface.o	\
 	hwxfsleep.o
 
-acpi-$(ACPI_FUTURE_USAGE) += hwtimer.o
+acpica-$(ACPI_FUTURE_USAGE) += hwtimer.o
 
-acpi-y +=		\
+acpica-y +=		\
 	nsaccess.o	\
 	nsalloc.o	\
 	nsarguments.o	\
@@ -103,9 +103,9 @@ acpi-y +=		\
 	nsxfname.o	\
 	nsxfobj.o
 
-acpi-$(ACPI_FUTURE_USAGE) += nsdumpdv.o
+acpica-$(ACPI_FUTURE_USAGE) += nsdumpdv.o
 
-acpi-y +=		\
+acpica-y +=		\
 	psargs.o	\
 	psloop.o	\
 	psobject.o	\
@@ -118,7 +118,7 @@ acpi-y +=		\
 	pswalk.o	\
 	psxface.o
 
-acpi-y +=		\
+acpica-y +=		\
 	rsaddr.o	\
 	rscalc.o	\
 	rscreate.o	\
@@ -134,7 +134,7 @@ acpi-y +=		\
 	rsutils.o	\
 	rsxface.o
 
-acpi-y +=		\
+acpica-y +=		\
 	tbdata.o	\
 	tbfadt.o	\
 	tbfind.o	\
@@ -145,7 +145,7 @@ acpi-y +=		\
 	tbxfload.o	\
 	tbxfroot.o
 
-acpi-y +=		\
+acpica-y +=		\
 	utaddress.o	\
 	utalloc.o	\
 	utbuffer.o	\
@@ -176,7 +176,7 @@ acpi-y +=		\
 	utxferror.o	\
 	utxfmutex.o
 
-acpi-$(ACPI_FUTURE_USAGE) +=	\
+acpica-$(ACPI_FUTURE_USAGE) +=	\
 	utcache.o		\
 	utfileio.o		\
 	utprint.o		\
diff --git a/drivers/pnp/pnpacpi/Makefile b/drivers/pnp/pnpacpi/Makefile
index 40c93da..2a7ae46 100644
--- a/drivers/pnp/pnpacpi/Makefile
+++ b/drivers/pnp/pnpacpi/Makefile
@@ -1,6 +1,6 @@
 #
 # Makefile for the kernel PNPACPI driver.
 #
-obj-y += pnp.o
+obj-y += pnpacpi.o
 
-pnp-y := core.o rsparser.o
+pnpacpi-y := core.o rsparser.o
diff --git a/init/Makefile b/init/Makefile
index 7bc47ee..566a9ff 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -2,23 +2,28 @@
 # Makefile for the linux kernel.
 #
 
-obj-y                          := main.o version.o mounts.o
+obj-y                          := main.o version.o do_mounts.o
+
 ifneq ($(CONFIG_BLK_DEV_INITRD),y)
 obj-y                          += noinitramfs.o
 else
-obj-$(CONFIG_BLK_DEV_INITRD)   += initramfs.o
+obj-y                          += initramfs.o do_mounts_initrd.o
+endif
+
+ifeq ($(CONFIG_BLK_DEV_RAM),y)
+obj-y                          += do_mounts_rd.o
 endif
+
+ifeq ($(CONFIG_BLK_DEV_MD),y)
+obj-y                          += do_mounts_md.o
+endif
+
 obj-$(CONFIG_GENERIC_CALIBRATE_DELAY) += calibrate.o
 
 ifneq ($(CONFIG_ARCH_INIT_TASK),y)
 obj-y                          += init_task.o
 endif
 
-mounts-y			:= do_mounts.o
-mounts-$(CONFIG_BLK_DEV_RAM)	+= do_mounts_rd.o
-mounts-$(CONFIG_BLK_DEV_INITRD)	+= do_mounts_initrd.o
-mounts-$(CONFIG_BLK_DEV_MD)	+= do_mounts_md.o
-
 # dependencies on generated files need to be listed explicitly
 $(obj)/version.o: include/generated/compile.h
 

Re: [PATCH 1/3] kbuild: Make targets names tree-wide unique on x86

[Peter Foley]

On Sun, Sep 14, 2014 at 6:18 AM, Kirill Tkhai <tkhai@yandex.ru> wrote:
> diff --git a/init/Makefile b/init/Makefile
> index 7bc47ee..566a9ff 100644
> --- a/init/Makefile
> +++ b/init/Makefile
> @@ -2,23 +2,28 @@
>  # Makefile for the linux kernel.
>  #
>
> -obj-y                          := main.o version.o mounts.o
> +obj-y                          := main.o version.o do_mounts.o
> +
>  ifneq ($(CONFIG_BLK_DEV_INITRD),y)
>  obj-y                          += noinitramfs.o
>  else
> -obj-$(CONFIG_BLK_DEV_INITRD)   += initramfs.o
> +obj-y                          += initramfs.o do_mounts_initrd.o
> +endif
> +
> +ifeq ($(CONFIG_BLK_DEV_RAM),y)
> +obj-y                          += do_mounts_rd.o
>  endif
> +
> +ifeq ($(CONFIG_BLK_DEV_MD),y)
> +obj-y                          += do_mounts_md.o
> +endif
> +
>  obj-$(CONFIG_GENERIC_CALIBRATE_DELAY) += calibrate.o
>
>  ifneq ($(CONFIG_ARCH_INIT_TASK),y)
>  obj-y                          += init_task.o
>  endif
>
> -mounts-y                       := do_mounts.o
> -mounts-$(CONFIG_BLK_DEV_RAM)   += do_mounts_rd.o
> -mounts-$(CONFIG_BLK_DEV_INITRD)        += do_mounts_initrd.o
> -mounts-$(CONFIG_BLK_DEV_MD)    += do_mounts_md.o
> -

Can't you keep the obj-$(CONFIG_*) syntax?
e.g.
obj-$(CONFIG_BLK_DEV_RAM) += do_mounts_rd.o

Re: [PATCH 1/3] kbuild: Make targets names tree-wide unique on x86

[Kirill Tkhai]

On 14.09.2014 19:57, Peter Foley wrote:
> On Sun, Sep 14, 2014 at 6:18 AM, Kirill Tkhai <tkhai@yandex.ru> wrote:
>> diff --git a/init/Makefile b/init/Makefile
>> index 7bc47ee..566a9ff 100644
>> --- a/init/Makefile
>> +++ b/init/Makefile
>> @@ -2,23 +2,28 @@
>>  # Makefile for the linux kernel.
>>  #
>>
>> -obj-y                          := main.o version.o mounts.o
>> +obj-y                          := main.o version.o do_mounts.o
>> +
>>  ifneq ($(CONFIG_BLK_DEV_INITRD),y)
>>  obj-y                          += noinitramfs.o
>>  else
>> -obj-$(CONFIG_BLK_DEV_INITRD)   += initramfs.o
>> +obj-y                          += initramfs.o do_mounts_initrd.o
>> +endif
>> +
>> +ifeq ($(CONFIG_BLK_DEV_RAM),y)
>> +obj-y                          += do_mounts_rd.o
>>  endif
>> +
>> +ifeq ($(CONFIG_BLK_DEV_MD),y)
>> +obj-y                          += do_mounts_md.o
>> +endif
>> +
>>  obj-$(CONFIG_GENERIC_CALIBRATE_DELAY) += calibrate.o
>>
>>  ifneq ($(CONFIG_ARCH_INIT_TASK),y)
>>  obj-y                          += init_task.o
>>  endif
>>
>> -mounts-y                       := do_mounts.o
>> -mounts-$(CONFIG_BLK_DEV_RAM)   += do_mounts_rd.o
>> -mounts-$(CONFIG_BLK_DEV_INITRD)        += do_mounts_initrd.o
>> -mounts-$(CONFIG_BLK_DEV_MD)    += do_mounts_md.o
>> -
> 
> Can't you keep the obj-$(CONFIG_*) syntax?
> e.g.
> obj-$(CONFIG_BLK_DEV_RAM) += do_mounts_rd.o
> 

They are need only in CONFIG_XXX=y case. They contain stubs
which are not compiled in case of =m. Look at rd_load_image()
for example.

So, here I prevent compilation errors, and make them uncompilable
in =m case like it used to be before.

Kirill

[PATCH 2/3] core: Save list of built-in drivers names

[Kirill Tkhai]

Create section *(__builtin_drivers_list) to store the list of drivers names.

Every driver name "modname" from directory "moddir" will be stored in array:

const char moddir_modname[] __attribute__((section("__builtin_drivers_list")) = "modname";

Using moddir prefix for variables names to prevent linking breakage
on the set of all architectures where dupricate names present.
The name template should be transmormed in something like __modname__name
in the future to catch duplicates, but now it's impossible.

Signed-off-by: Kirill Tkhai <ktkhai@parallels.com>
---
 include/asm-generic/vmlinux.lds.h |    3 +++
 scripts/Makefile.build            |   14 ++++++++++----
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 5ba0360..5bc6d56 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -237,6 +237,9 @@
 		*(__tracepoints_ptrs)	/* Tracepoints: pointer array */\
 		VMLINUX_SYMBOL(__stop___tracepoints_ptrs) = .;		\
 		*(__tracepoints_strings)/* Tracepoints: strings */	\
+		VMLINUX_SYMBOL(__start_builtin_drivers_list) = .;	\
+		*(__builtin_drivers_list)				\
+		VMLINUX_SYMBOL(__stop_builtin_drivers_list) = .;	\
 	}								\
 									\
 	.rodata1          : AT(ADDR(.rodata1) - LOAD_OFFSET) {		\
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index bf3e677..e158a4d 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -136,6 +136,7 @@ $(obj-m)              : quiet_modtag := [M]
 
 # Default for not multi-part modules
 modname = $(basetarget)
+modname_c_var = `echo $(kbuild-dir)/$(modname) | sed 's/\.\///g' | sed 's/-/_/g' | sed 's/\//__/g'`
 
 $(multi-objs-m)         : modname = $(modname-multi)
 $(multi-objs-m:.o=.i)   : modname = $(modname-multi)
@@ -376,11 +377,16 @@ $(filter $(addprefix $(obj)/,         \
 $($(subst $(obj)/,,$(@:.o=-objs)))    \
 $($(subst $(obj)/,,$(@:.o=-y)))), $^)
 
-quiet_cmd_link_multi-y = LD      $@
-cmd_link_multi-y = $(LD) $(ld_flags) -r -o $@ $(link_multi_deps) $(cmd_secanalysis)
-
 quiet_cmd_link_multi-m = LD [M]  $@
-cmd_link_multi-m = $(cmd_link_multi-y)
+cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(link_multi_deps) $(cmd_secanalysis)
+
+quiet_cmd_link_multi-y = LD      $@
+cmd_link_multi-y = \
+	echo "const char "$(modname_c_var)"[] __attribute__((section(\"__builtin_drivers_list\"))) " \
+	     "__attribute__ ((aligned(sizeof(unsigned long)))) = \""$(modname)"\";" > $(kbuild-dir)/.$(modname).c; \
+	$(CC) $(c_flags) -c $(kbuild-dir)/.$(modname).c -o $(kbuild-dir)/.$(modname).o; \
+	$(LD) $(ld_flags) -r -o $@ $(link_multi_deps) $(kbuild-dir)/.$(modname).o $(cmd_secanalysis); \
+	rm -f $(kbuild-dir)/.$(modname).c
 
 # We would rather have a list of rules like
 # 	foo.o: $(foo-objs)

[PATCH 3/3] core: create /proc/built-in file to show the list of built-in drivers

[Kirill Tkhai]

Signed-off-by: kirill tkhai <ktkhai@parallels.com>
---
 fs/proc/Makefile  |    1 +
 fs/proc/builtin.c |   70 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)
 create mode 100644 fs/proc/builtin.c

diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..1e13361 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -10,6 +10,7 @@ proc-$(CONFIG_MMU)	:= task_mmu.o
 proc-y       += inode.o root.o base.o generic.o array.o \
 		fd.o
 proc-$(CONFIG_TTY)      += proc_tty.o
+proc-y	+= builtin.o
 proc-y	+= cmdline.o
 proc-y	+= consoles.o
 proc-y	+= cpuinfo.o
diff --git a/fs/proc/builtin.c b/fs/proc/builtin.c
new file mode 100644
index 0000000..2d49980
--- /dev/null
+++ b/fs/proc/builtin.c
@@ -0,0 +1,70 @@
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+
+extern char __start_builtin_drivers_list[], __stop_builtin_drivers_list[];
+
+static void *b_start(struct seq_file *m, loff_t *pos)
+{
+	unsigned long size = (unsigned long)__stop_builtin_drivers_list -
+			     (unsigned long)__start_builtin_drivers_list;
+	if (*pos) {
+		/* Skip all !'\0' symbols */
+		while (*pos <= size &&  *(__start_builtin_drivers_list + *pos))
+			++*pos;
+		/* Skip all  '\0' symbols */
+		while (*pos <= size && !*(__start_builtin_drivers_list + *pos))
+			++*pos;
+	}
+
+	if (*pos >= size)
+		return NULL;
+
+	return __start_builtin_drivers_list + *pos;
+}
+
+static void *b_next(struct seq_file *m, void *cur, loff_t *pos)
+{
+	++*pos;
+
+	return b_start(m, pos);
+}
+
+static void b_stop(struct seq_file *m, void *p)
+{
+}
+
+static int b_show(struct seq_file *m, void *p)
+{
+	seq_printf(m, "%s\n", (const char *)p);
+
+	return 0;
+}
+
+static const struct seq_operations builtin_op = {
+	.start = b_start,
+	.next = b_next,
+	.stop = b_stop,
+	.show = b_show
+};
+
+static int builtin_open(struct inode *inode, struct file *file)
+{
+	return seq_open(file, &builtin_op);
+}
+
+static const struct file_operations builtin_operations = {
+	.open = builtin_open,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = seq_release_private,
+};
+
+static int __init proc_builtin_init(void)
+{
+	proc_create("built-in", S_IRUGO, NULL, &builtin_operations);
+	return 0;
+}
+
+fs_initcall(proc_builtin_init);

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Greg KH]

On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
> This series implements a possibility to show the list of built-in drivers
> to userspace. The names of drivers will be the same as when they are modules.

Have you looked at /sys/modules/ ?  Doesn't that show what you want
here?

> So, if your system has "loop" driver then it appears either in /proc/modules
> or in /proc/built-in and userspace will be able to know about this.
> 
> Now this is impossible. The only way to get kernel configuration is
> /proc/config.gz, but CONFIG_* names can change from time to time. Module
> names are more or less standardized.

Module names aren't "standardized", we change them at times when needed,
just like CONFIG_ names.

What is your end goal here?  As you say, config.gz is the real kernel
configuration, just having a list of modules built in isn't going to
help much in getting a working kernel config without it.

thanks,

greg k-h

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Oleg Nesterov]

On 09/14, Greg KH wrote:
>
> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
> > This series implements a possibility to show the list of built-in drivers
> > to userspace. The names of drivers will be the same as when they are modules.
>
> Have you looked at /sys/modules/ ?  Doesn't that show what you want
> here?

Well, /sys/module/ doesn't list the modules (drivers) compiled in. Say,
/sys/module/kernel. And it can't help a user to figure out that, say, the
loop driver is already "loaded" because CONFIG_BLK_DEV_LOOP=y.

> Module names aren't "standardized", we change them at times when needed,
> just like CONFIG_ names.

OK, but still the name will be the same, in /proc/modules or /proc/builtin.

> What is your end goal here?  As you say, config.gz is the real kernel
> configuration, just having a list of modules built in isn't going to
> help much in getting a working kernel config without it.

Perhaps you are right... but otoh perhaps this can can be useful anyway.
Again, a user can know about "insmod loop", but he can know nothing
about CONFIG_ names.

That said, I do not really understand 2/3. Not only I do not understand
this kbuild magic, I am not sure I understand what /proc/built-in will
actually show.

To me it would be better to change the "ifndef MODULE" version of
module_init() to add KBUILD_MODNAME into __builtin_drivers_list[].

Yes, module_init() is overused. Say, why does kernel/kprobes.c use
module_init() ? This looks confusing, this code can't be compiled as a
module. And it seems that it has a lot more users which should have used
__initcall() instead.

In short, I dunno ;)

Oleg.

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Kirill Tkhai]

On 14.09.2014 21:27, Oleg Nesterov wrote:
> On 09/14, Greg KH wrote:
>>
>> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
>>> This series implements a possibility to show the list of built-in drivers
>>> to userspace. The names of drivers will be the same as when they are modules.
>>
>> Have you looked at /sys/modules/ ?  Doesn't that show what you want
>> here?
> 
> Well, /sys/module/ doesn't list the modules (drivers) compiled in. Say,
> /sys/module/kernel. And it can't help a user to figure out that, say, the
> loop driver is already "loaded" because CONFIG_BLK_DEV_LOOP=y.
> 
>> Module names aren't "standardized", we change them at times when needed,
>> just like CONFIG_ names.
> 
> OK, but still the name will be the same, in /proc/modules or /proc/builtin.
> 
>> What is your end goal here?  As you say, config.gz is the real kernel
>> configuration, just having a list of modules built in isn't going to
>> help much in getting a working kernel config without it.
> 
> Perhaps you are right... but otoh perhaps this can can be useful anyway.
> Again, a user can know about "insmod loop", but he can know nothing
> about CONFIG_ names.
> 
> That said, I do not really understand 2/3. Not only I do not understand
> this kbuild magic, I am not sure I understand what /proc/built-in will
> actually show.

It's a list of drivers, one driver per line:

loop
ipv4
ipv5
ipv6
ipv7
ipv8
etc ;)

> To me it would be better to change the "ifndef MODULE" version of
> module_init() to add KBUILD_MODNAME into __builtin_drivers_list[].
> 
> Yes, module_init() is overused. Say, why does kernel/kprobes.c use
> module_init() ? This looks confusing, this code can't be compiled as a
> module. And it seems that it has a lot more users which should have used
> __initcall() instead

Yeh, the realization may be different. I do not insist on additional
section. I'm happy listening to advices.
.
> In short, I dunno ;)

Thanks,
Kirill

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Richard Weinberger]

On Sun, Sep 14, 2014 at 7:57 PM, Kirill Tkhai <tkhai@yandex.ru> wrote:
> On 14.09.2014 21:27, Oleg Nesterov wrote:
>> On 09/14, Greg KH wrote:
>>>
>>> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
>>>> This series implements a possibility to show the list of built-in drivers
>>>> to userspace. The names of drivers will be the same as when they are modules.
>>>
>>> Have you looked at /sys/modules/ ?  Doesn't that show what you want
>>> here?
>>
>> Well, /sys/module/ doesn't list the modules (drivers) compiled in. Say,
>> /sys/module/kernel. And it can't help a user to figure out that, say, the
>> loop driver is already "loaded" because CONFIG_BLK_DEV_LOOP=y.
>>
>>> Module names aren't "standardized", we change them at times when needed,
>>> just like CONFIG_ names.
>>
>> OK, but still the name will be the same, in /proc/modules or /proc/builtin.
>>
>>> What is your end goal here?  As you say, config.gz is the real kernel
>>> configuration, just having a list of modules built in isn't going to
>>> help much in getting a working kernel config without it.
>>
>> Perhaps you are right... but otoh perhaps this can can be useful anyway.
>> Again, a user can know about "insmod loop", but he can know nothing
>> about CONFIG_ names.
>>
>> That said, I do not really understand 2/3. Not only I do not understand
>> this kbuild magic, I am not sure I understand what /proc/built-in will
>> actually show.
>
> It's a list of drivers, one driver per line:

Built-in modules or drivers? :-)

-- 
Thanks,
//richard

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Kirill Tkhai]

On 14.09.2014 22:12, Richard Weinberger wrote:
> On Sun, Sep 14, 2014 at 7:57 PM, Kirill Tkhai <tkhai@yandex.ru> wrote:
>> On 14.09.2014 21:27, Oleg Nesterov wrote:
>>> On 09/14, Greg KH wrote:
>>>>
>>>> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
>>>>> This series implements a possibility to show the list of built-in drivers
>>>>> to userspace. The names of drivers will be the same as when they are modules.
>>>>
>>>> Have you looked at /sys/modules/ ?  Doesn't that show what you want
>>>> here?
>>>
>>> Well, /sys/module/ doesn't list the modules (drivers) compiled in. Say,
>>> /sys/module/kernel. And it can't help a user to figure out that, say, the
>>> loop driver is already "loaded" because CONFIG_BLK_DEV_LOOP=y.
>>>
>>>> Module names aren't "standardized", we change them at times when needed,
>>>> just like CONFIG_ names.
>>>
>>> OK, but still the name will be the same, in /proc/modules or /proc/builtin.
>>>
>>>> What is your end goal here?  As you say, config.gz is the real kernel
>>>> configuration, just having a list of modules built in isn't going to
>>>> help much in getting a working kernel config without it.
>>>
>>> Perhaps you are right... but otoh perhaps this can can be useful anyway.
>>> Again, a user can know about "insmod loop", but he can know nothing
>>> about CONFIG_ names.
>>>
>>> That said, I do not really understand 2/3. Not only I do not understand
>>> this kbuild magic, I am not sure I understand what /proc/built-in will
>>> actually show.
>>
>> It's a list of drivers, one driver per line:
> 
> Built-in modules or drivers? :-)
> 

It's for boolean CONFIG_XXX too. Some targets have names, not obj-y.
For example, acpi. I did not change them.

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Oleg Nesterov]

On 09/14, Kirill Tkhai wrote:
>
> On 14.09.2014 21:27, Oleg Nesterov wrote:
> >
> > That said, I do not really understand 2/3. Not only I do not understand
> > this kbuild magic, I am not sure I understand what /proc/built-in will
> > actually show.
>
> It's a list of drivers, one driver per line:
>
> loop
> ipv4
> ipv5
> ipv6
> ipv7
> ipv8
> etc ;)

which drivers ? ;)

OK, I blindly applied this series to my test kernel tree and the
output is:

	$ cat /proc/built-in
	proc
	devpts
	ext3
	jbd
	ramfs
	hugetlbfs
	debugfs
	crypto
	crypto_algapi
	pcieportdrv
	acpi
	acpica
	pnp
	pnpacpi
	8250
	input-core
	netfilter
	unix

and where is, say, af_packet driver? I have CONFIG_PACKET=y. Or, where
is my deadline_iosched/cfq_iosched modules compiled in?

> > To me it would be better to change the "ifndef MODULE" version of
> > module_init() to add KBUILD_MODNAME into __builtin_drivers_list[].
> >
> > Yes, module_init() is overused. Say, why does kernel/kprobes.c use
> > module_init() ? This looks confusing, this code can't be compiled as a
> > module. And it seems that it has a lot more users which should have used
> > __initcall() instead
>
> Yeh, the realization may be different. I do not insist on additional
> section.

The additional sction is fine, I think. I only meant that module_init()
itself can be used to add a module name into that section.

But of course I won't insist. And again, module_init() is abused by the
non-modular kernel code.

Oleg.

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Kirill Tkhai]

On 14.09.2014 19:38, Greg KH wrote:
> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
>> This series implements a possibility to show the list of built-in drivers
>> to userspace. The names of drivers will be the same as when they are modules.
> 
> Have you looked at /sys/modules/ ?  Doesn't that show what you want
> here?

There are only the drivers in "/sys/module" which have parameters.
Drivers without parameters do not appear there.

>> So, if your system has "loop" driver then it appears either in /proc/modules
>> or in /proc/built-in and userspace will be able to know about this.
>>
>> Now this is impossible. The only way to get kernel configuration is
>> /proc/config.gz, but CONFIG_* names can change from time to time. Module
>> names are more or less standardized.
> 
> Module names aren't "standardized", we change them at times when needed,
> just like CONFIG_ names.
> 
> What is your end goal here?  As you say, config.gz is the real kernel
> configuration, just having a list of modules built in isn't going to
> help much in getting a working kernel config without it.

It looks like userspace applications oriented on modules names rather
than on CONFIG_XXX parameters. /proc/config.gz is optional and userspace
applications can't base on it.

For example, when I compile "loop" module built-in and "loop" is in
/etc/modules, init script warns about this module is not present and
can't be autoloaded. The script does not store CONFIG_XXX <-> module_xxx
conformity. And nobody stores it.

When iptables wants extra functionality, it requests a module. Etc.

Nobody is oriented on CONFIG_XXX parameters. It would be simple for
userspace to add a support of /proc/built-in analysing. It's very
similar to /proc/modules.

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Greg KH]

On Sun, Sep 14, 2014 at 09:31:58PM +0400, Kirill Tkhai wrote:
> On 14.09.2014 19:38, Greg KH wrote:
> > On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
> >> This series implements a possibility to show the list of built-in drivers
> >> to userspace. The names of drivers will be the same as when they are modules.
> > 
> > Have you looked at /sys/modules/ ?  Doesn't that show what you want
> > here?
> 
> There are only the drivers in "/sys/module" which have parameters.
> Drivers without parameters do not appear there.

Ah, didn't realize that.  Should be easy to fix though, if you really
wanted to list the modules.  Much better than a random proc file that
you have to parse :)

> >> So, if your system has "loop" driver then it appears either in /proc/modules
> >> or in /proc/built-in and userspace will be able to know about this.
> >>
> >> Now this is impossible. The only way to get kernel configuration is
> >> /proc/config.gz, but CONFIG_* names can change from time to time. Module
> >> names are more or less standardized.
> > 
> > Module names aren't "standardized", we change them at times when needed,
> > just like CONFIG_ names.
> > 
> > What is your end goal here?  As you say, config.gz is the real kernel
> > configuration, just having a list of modules built in isn't going to
> > help much in getting a working kernel config without it.
> 
> It looks like userspace applications oriented on modules names rather
> than on CONFIG_XXX parameters. /proc/config.gz is optional and userspace
> applications can't base on it.
> 
> For example, when I compile "loop" module built-in and "loop" is in
> /etc/modules, init script warns about this module is not present and
> can't be autoloaded. The script does not store CONFIG_XXX <-> module_xxx
> conformity. And nobody stores it.
> 
> When iptables wants extra functionality, it requests a module. Etc.
> 
> Nobody is oriented on CONFIG_XXX parameters. It would be simple for
> userspace to add a support of /proc/built-in analysing. It's very
> similar to /proc/modules.

Shouldn't userspace focus on the functionality a module provides, not
the module name itself?  Can't a test for the loop "module" just test to
see if the loop control device is present?  Same for iptables (there's
modprobe rules for iptable modules I think...)

In other words, don't focus on the module names, focus on the userspace
function a module provides, there should always be a way to check that
at run time (if not, then the module doesn't actually do much...)

thanks,

greg k-h

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Kirill Tkhai]

On 14.09.2014 21:39, Greg KH wrote:
> On Sun, Sep 14, 2014 at 09:31:58PM +0400, Kirill Tkhai wrote:
>> On 14.09.2014 19:38, Greg KH wrote:
>>> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
>>>> This series implements a possibility to show the list of built-in drivers
>>>> to userspace. The names of drivers will be the same as when they are modules.
>>>
>>> Have you looked at /sys/modules/ ?  Doesn't that show what you want
>>> here?
>>
>> There are only the drivers in "/sys/module" which have parameters.
>> Drivers without parameters do not appear there.
> 
> Ah, didn't realize that.  Should be easy to fix though, if you really
> wanted to list the modules.  Much better than a random proc file that
> you have to parse :)

But it looks like one file is better than many new directories.
Furthermore some utils already may consider /sys/module directory as
a directory where all drivers have parameters. Is it good if we add
new ones of different type there?

>>>> So, if your system has "loop" driver then it appears either in /proc/modules
>>>> or in /proc/built-in and userspace will be able to know about this.
>>>>
>>>> Now this is impossible. The only way to get kernel configuration is
>>>> /proc/config.gz, but CONFIG_* names can change from time to time. Module
>>>> names are more or less standardized.
>>>
>>> Module names aren't "standardized", we change them at times when needed,
>>> just like CONFIG_ names.
>>>
>>> What is your end goal here?  As you say, config.gz is the real kernel
>>> configuration, just having a list of modules built in isn't going to
>>> help much in getting a working kernel config without it.
>>
>> It looks like userspace applications oriented on modules names rather
>> than on CONFIG_XXX parameters. /proc/config.gz is optional and userspace
>> applications can't base on it.
>>
>> For example, when I compile "loop" module built-in and "loop" is in
>> /etc/modules, init script warns about this module is not present and
>> can't be autoloaded. The script does not store CONFIG_XXX <-> module_xxx
>> conformity. And nobody stores it.
>>
>> When iptables wants extra functionality, it requests a module. Etc.
>>
>> Nobody is oriented on CONFIG_XXX parameters. It would be simple for
>> userspace to add a support of /proc/built-in analysing. It's very
>> similar to /proc/modules.
> 
> Shouldn't userspace focus on the functionality a module provides, not
> the module name itself?  Can't a test for the loop "module" just test to
> see if the loop control device is present?  Same for iptables (there's
> modprobe rules for iptable modules I think...)
> 
> In other words, don't focus on the module names, focus on the userspace
> function a module provides, there should always be a way to check that
> at run time (if not, then the module doesn't actually do much...)

Hm, I'm not sure that anybody stores CONFIG_XXX <-> module_xxx
conformity. Everybody bases on module name. If application is seeing
CONFIG_XXX=m, but the functionality, which it want's, is not available,
what it has to do? How should it convert CONFIG_XXX to module name?
So, many applications want module name instead of CONFIG_XXX, I believe.

Kirill

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Greg KH]

On Sun, Sep 14, 2014 at 10:05:46PM +0400, Kirill Tkhai wrote:
> On 14.09.2014 21:39, Greg KH wrote:
> > On Sun, Sep 14, 2014 at 09:31:58PM +0400, Kirill Tkhai wrote:
> >> On 14.09.2014 19:38, Greg KH wrote:
> >>> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
> >>>> This series implements a possibility to show the list of built-in drivers
> >>>> to userspace. The names of drivers will be the same as when they are modules.
> >>>
> >>> Have you looked at /sys/modules/ ?  Doesn't that show what you want
> >>> here?
> >>
> >> There are only the drivers in "/sys/module" which have parameters.
> >> Drivers without parameters do not appear there.
> > 
> > Ah, didn't realize that.  Should be easy to fix though, if you really
> > wanted to list the modules.  Much better than a random proc file that
> > you have to parse :)
> 
> But it looks like one file is better than many new directories.

Why?

> Furthermore some utils already may consider /sys/module directory as
> a directory where all drivers have parameters. Is it good if we add
> new ones of different type there?

What would break if you add new directories there with no parameters?

> >>>> So, if your system has "loop" driver then it appears either in /proc/modules
> >>>> or in /proc/built-in and userspace will be able to know about this.
> >>>>
> >>>> Now this is impossible. The only way to get kernel configuration is
> >>>> /proc/config.gz, but CONFIG_* names can change from time to time. Module
> >>>> names are more or less standardized.
> >>>
> >>> Module names aren't "standardized", we change them at times when needed,
> >>> just like CONFIG_ names.
> >>>
> >>> What is your end goal here?  As you say, config.gz is the real kernel
> >>> configuration, just having a list of modules built in isn't going to
> >>> help much in getting a working kernel config without it.
> >>
> >> It looks like userspace applications oriented on modules names rather
> >> than on CONFIG_XXX parameters. /proc/config.gz is optional and userspace
> >> applications can't base on it.
> >>
> >> For example, when I compile "loop" module built-in and "loop" is in
> >> /etc/modules, init script warns about this module is not present and
> >> can't be autoloaded. The script does not store CONFIG_XXX <-> module_xxx
> >> conformity. And nobody stores it.
> >>
> >> When iptables wants extra functionality, it requests a module. Etc.
> >>
> >> Nobody is oriented on CONFIG_XXX parameters. It would be simple for
> >> userspace to add a support of /proc/built-in analysing. It's very
> >> similar to /proc/modules.
> > 
> > Shouldn't userspace focus on the functionality a module provides, not
> > the module name itself?  Can't a test for the loop "module" just test to
> > see if the loop control device is present?  Same for iptables (there's
> > modprobe rules for iptable modules I think...)
> > 
> > In other words, don't focus on the module names, focus on the userspace
> > function a module provides, there should always be a way to check that
> > at run time (if not, then the module doesn't actually do much...)
> 
> Hm, I'm not sure that anybody stores CONFIG_XXX <-> module_xxx
> conformity. Everybody bases on module name. If application is seeing
> CONFIG_XXX=m, but the functionality, which it want's, is not available,
> what it has to do? How should it convert CONFIG_XXX to module name?

Why would an application ever care about CONFIG_XXX at runtime?

> So, many applications want module name instead of CONFIG_XXX, I believe.

No, they want the functionality that a module provides, not the module
name, or some random configuation option.

It seems like you are trying to solve a problem that isn't there.  What
program is broken right now that this new proc file (or sysfs directory)
would fix?

thanks,

greg k-h

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Kirill Tkhai]

On 14.09.2014 22:13, Greg KH wrote:
> On Sun, Sep 14, 2014 at 10:05:46PM +0400, Kirill Tkhai wrote:
>> On 14.09.2014 21:39, Greg KH wrote:
>>> On Sun, Sep 14, 2014 at 09:31:58PM +0400, Kirill Tkhai wrote:
>>>> On 14.09.2014 19:38, Greg KH wrote:
>>>>> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
>>>>>> This series implements a possibility to show the list of built-in drivers
>>>>>> to userspace. The names of drivers will be the same as when they are modules.
>>>>>
>>>>> Have you looked at /sys/modules/ ?  Doesn't that show what you want
>>>>> here?
>>>>
>>>> There are only the drivers in "/sys/module" which have parameters.
>>>> Drivers without parameters do not appear there.
>>>
>>> Ah, didn't realize that.  Should be easy to fix though, if you really
>>> wanted to list the modules.  Much better than a random proc file that
>>> you have to parse :)
>>
>> But it looks like one file is better than many new directories.
> 
> Why?

It's just an unification with /proc/modules. Why should we do any
difference between external and built-in modules? It's the same,
it's similar, it's better to parse when they can be shown similar.

> 
>> Furthermore some utils already may consider /sys/module directory as
>> a directory where all drivers have parameters. Is it good if we add
>> new ones of different type there?
> 
> What would break if you add new directories there with no parameters?

I do not know no one, but it does not mean they do not exist. I just do
not want to break anything which already exists.

>>>>>> So, if your system has "loop" driver then it appears either in /proc/modules
>>>>>> or in /proc/built-in and userspace will be able to know about this.
>>>>>>
>>>>>> Now this is impossible. The only way to get kernel configuration is
>>>>>> /proc/config.gz, but CONFIG_* names can change from time to time. Module
>>>>>> names are more or less standardized.
>>>>>
>>>>> Module names aren't "standardized", we change them at times when needed,
>>>>> just like CONFIG_ names.
>>>>>
>>>>> What is your end goal here?  As you say, config.gz is the real kernel
>>>>> configuration, just having a list of modules built in isn't going to
>>>>> help much in getting a working kernel config without it.
>>>>
>>>> It looks like userspace applications oriented on modules names rather
>>>> than on CONFIG_XXX parameters. /proc/config.gz is optional and userspace
>>>> applications can't base on it.
>>>>
>>>> For example, when I compile "loop" module built-in and "loop" is in
>>>> /etc/modules, init script warns about this module is not present and
>>>> can't be autoloaded. The script does not store CONFIG_XXX <-> module_xxx
>>>> conformity. And nobody stores it.
>>>>
>>>> When iptables wants extra functionality, it requests a module. Etc.
>>>>
>>>> Nobody is oriented on CONFIG_XXX parameters. It would be simple for
>>>> userspace to add a support of /proc/built-in analysing. It's very
>>>> similar to /proc/modules.
>>>
>>> Shouldn't userspace focus on the functionality a module provides, not
>>> the module name itself?  Can't a test for the loop "module" just test to
>>> see if the loop control device is present?  Same for iptables (there's
>>> modprobe rules for iptable modules I think...)
>>>
>>> In other words, don't focus on the module names, focus on the userspace
>>> function a module provides, there should always be a way to check that
>>> at run time (if not, then the module doesn't actually do much...)
>>
>> Hm, I'm not sure that anybody stores CONFIG_XXX <-> module_xxx
>> conformity. Everybody bases on module name. If application is seeing
>> CONFIG_XXX=m, but the functionality, which it want's, is not available,
>> what it has to do? How should it convert CONFIG_XXX to module name?
> 
> Why would an application ever care about CONFIG_XXX at runtime?
> 
>> So, many applications want module name instead of CONFIG_XXX, I believe.
> 
> No, they want the functionality that a module provides, not the module
> name, or some random configuation option.
> 
> It seems like you are trying to solve a problem that isn't there.  What
> program is broken right now that this new proc file (or sysfs directory)
> would fix?

The initial reason was I'm building custom kernels for more than 10
years (not so long, I agree), and every boot I see a big list of modules
from distribution /etc/module, which can't be autoloaded. I prefer to
build drivers in kernel. I tried to find is there a way for userspace to
understand that a module are present, but there is no a way. So this is
a reason.

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Greg KH]

On Sun, Sep 14, 2014 at 10:35:58PM +0400, Kirill Tkhai wrote:
> On 14.09.2014 22:13, Greg KH wrote:
> > On Sun, Sep 14, 2014 at 10:05:46PM +0400, Kirill Tkhai wrote:
> >> On 14.09.2014 21:39, Greg KH wrote:
> >>> On Sun, Sep 14, 2014 at 09:31:58PM +0400, Kirill Tkhai wrote:
> >>>> On 14.09.2014 19:38, Greg KH wrote:
> >>>>> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
> >>>>>> This series implements a possibility to show the list of built-in drivers
> >>>>>> to userspace. The names of drivers will be the same as when they are modules.
> >>>>>
> >>>>> Have you looked at /sys/modules/ ?  Doesn't that show what you want
> >>>>> here?
> >>>>
> >>>> There are only the drivers in "/sys/module" which have parameters.
> >>>> Drivers without parameters do not appear there.
> >>>
> >>> Ah, didn't realize that.  Should be easy to fix though, if you really
> >>> wanted to list the modules.  Much better than a random proc file that
> >>> you have to parse :)
> >>
> >> But it looks like one file is better than many new directories.
> > 
> > Why?
> 
> It's just an unification with /proc/modules. Why should we do any
> difference between external and built-in modules? It's the same,
> it's similar, it's better to parse when they can be shown similar.

/proc/modules is for loaded modules, and it includes lots of information
that tools rely on.  It is also a very old file, no new
non-process-related proc/ files should be created anymore.  It's been
that way since sysfs was created (and one of the reasons for sysfs.)

> > No, they want the functionality that a module provides, not the module
> > name, or some random configuation option.
> > 
> > It seems like you are trying to solve a problem that isn't there.  What
> > program is broken right now that this new proc file (or sysfs directory)
> > would fix?
> 
> The initial reason was I'm building custom kernels for more than 10
> years (not so long, I agree), and every boot I see a big list of modules
> from distribution /etc/module, which can't be autoloaded. I prefer to
> build drivers in kernel. I tried to find is there a way for userspace to
> understand that a module are present, but there is no a way. So this is
> a reason.

I don't understand, my distro doesn't have any modules listed in
/etc/module that aren't autoloaded, perhaps you should work with your
distro on that :)

And how would these patches remove those config files?

Again, focus on kernel functionality, not module names or config
options, and you should be fine.

thanks,

greg k-h

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Kirill Tkhai]

14.09.2014, 22:56, "Greg KH" <gregkh@linuxfoundation.org>:
> On Sun, Sep 14, 2014 at 10:35:58PM +0400, Kirill Tkhai wrote:
>>  On 14.09.2014 22:13, Greg KH wrote:
>>>  On Sun, Sep 14, 2014 at 10:05:46PM +0400, Kirill Tkhai wrote:
>>>>  On 14.09.2014 21:39, Greg KH wrote:
>>>>>  On Sun, Sep 14, 2014 at 09:31:58PM +0400, Kirill Tkhai wrote:
>>>>>>  On 14.09.2014 19:38, Greg KH wrote:
>>>>>>>  On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
>>>>>>>>  This series implements a possibility to show the list of built-in drivers
>>>>>>>>  to userspace. The names of drivers will be the same as when they are modules.
>>>>>>>  Have you looked at /sys/modules/ ?  Doesn't that show what you want
>>>>>>>  here?
>>>>>>  There are only the drivers in "/sys/module" which have parameters.
>>>>>>  Drivers without parameters do not appear there.
>>>>>  Ah, didn't realize that.  Should be easy to fix though, if you really
>>>>>  wanted to list the modules.  Much better than a random proc file that
>>>>>  you have to parse :)
>>>>  But it looks like one file is better than many new directories.
>>>  Why?
>>  It's just an unification with /proc/modules. Why should we do any
>>  difference between external and built-in modules? It's the same,
>>  it's similar, it's better to parse when they can be shown similar.
>
> /proc/modules is for loaded modules, and it includes lots of information
> that tools rely on.  It is also a very old file, no new
> non-process-related proc/ files should be created anymore.  It's been
> that way since sysfs was created (and one of the reasons for sysfs.)
>>>  No, they want the functionality that a module provides, not the module
>>>  name, or some random configuation option.
>>>
>>>  It seems like you are trying to solve a problem that isn't there.  What
>>>  program is broken right now that this new proc file (or sysfs directory)
>>>  would fix?
>>  The initial reason was I'm building custom kernels for more than 10
>>  years (not so long, I agree), and every boot I see a big list of modules
>>  from distribution /etc/module, which can't be autoloaded. I prefer to
>>  build drivers in kernel. I tried to find is there a way for userspace to
>>  understand that a module are present, but there is no a way. So this is
>>  a reason.
>
> I don't understand, my distro doesn't have any modules listed in
> /etc/module that aren't autoloaded, perhaps you should work with your
> distro on that :)
>
> And how would these patches remove those config files?
>
> Again, focus on kernel functionality, not module names or config
> options, and you should be fine.

Ok, I have no objections anymore.

Thanks,
Kirill

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Lucas De Marchi]

On Sun, Sep 14, 2014 at 3:56 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Sun, Sep 14, 2014 at 10:35:58PM +0400, Kirill Tkhai wrote:
>>
>> It's just an unification with /proc/modules. Why should we do any
>> difference between external and built-in modules? It's the same,
>> it's similar, it's better to parse when they can be shown similar.
>
> /proc/modules is for loaded modules, and it includes lots of information
> that tools rely on.  It is also a very old file, no new
> non-process-related proc/ files should be created anymore.  It's been
> that way since sysfs was created (and one of the reasons for sysfs.)


Yeah. And let me add that kmod treats /proc/modules as deprecated.
It's way nicer to get the information from sysfs. See
https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/tree/README#n116

>> > No, they want the functionality that a module provides, not the module
>> > name, or some random configuation option.
>> >
>> > It seems like you are trying to solve a problem that isn't there.  What
>> > program is broken right now that this new proc file (or sysfs directory)
>> > would fix?
>>
>> The initial reason was I'm building custom kernels for more than 10
>> years (not so long, I agree), and every boot I see a big list of modules
>> from distribution /etc/module, which can't be autoloaded. I prefer to
>> build drivers in kernel. I tried to find is there a way for userspace to
>> understand that a module are present, but there is no a way. So this is
>> a reason.

you're probably using ancient userspace. kmod checks the
modules.builtin file generated by the kernel buildsys so "modprobe
buitin-module" doesn't return an error.

> Again, focus on kernel functionality, not module names or config
> options, and you should be fine.

Yeah... and if you do this way you may not even bother about the
module itself. See the output of "kmod static-nodes". These nodes are
created by init even if the module itself is not loaded. The right
module will be loaded when the node is first accessed. And that
includes the "loop" module you mention.

$ kmod static-nodes | grep -A3 loop
Module: loop
        Device node: /dev/loop-control
                Type: character device
                Major: 10
                Minor: 237

-- 

Lucas De Marchi

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Michal Marek]

On 2014-09-14 19:31, Kirill Tkhai wrote:
> For example, when I compile "loop" module built-in and "loop" is in
> /etc/modules, init script warns about this module is not present and
> can't be autoloaded. The script does not store CONFIG_XXX <-> module_xxx
> conformity. And nobody stores it.

You must be using really old userspace. I have loop modular, but

# modprobe ipv6; echo $?
0
# modprobe --show-depends ipv6
builtin ipv6
# strace -eopen modprobe ipv6
...
open("/lib/modules/3.12.15-3-default/modules.builtin.bin",
O_RDONLY|O_CLOEXEC) = 3
+++ exited with 0 +++
# modprobe --version
kmod version 18

Michal

Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

[Michal Marek]

On 2014-09-14 17:38, Greg KH wrote:
> On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:
>> This series implements a possibility to show the list of built-in drivers
>> to userspace. The names of drivers will be the same as when they are modules.
> 
> Have you looked at /sys/modules/ ?  Doesn't that show what you want
> here?

Plus, we have /lib/modules/.../modules.builtin, which is already
understood by kmod. And if you badly need to display the list in /proc,
then please just reuse the modules.builtin file.

Michal