Implement /proc/built-in file similar to /proc/modules

init/Makefile +12 -2

index 7bc47ee..566a9ff 100644
@@ -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

Quoted 32 lines · Kirill Tkhai

init/Makefile +12 -2

index 7bc47ee..566a9ff 100644
@@ -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
 

init/Makefile line 21

Quoted 5 lines

init/Makefile +0 -5

-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

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.

Quoted 2 lines · 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.

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

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.

Quoted 7 lines · Greg KH

Quoted 2 lines · 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.

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.

Quoted 2 lines

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.

Quoted 3 lines

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 ;)

Quoted 26 lines · Oleg Nesterov

Quoted 7 lines · Greg KH

Quoted 2 lines · 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.

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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:

Quoted 27 lines · Kirill Tkhai

Quoted 26 lines · Oleg Nesterov

Quoted 7 lines · Greg KH

Quoted 2 lines · 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.

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

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? :-)

Quoted 4 lines · Oleg Nesterov

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 ;)

Quoted 7 lines

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.

Quoted 2 lines · 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.

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

Quoted 6 lines

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.

Quoted 6 lines · Greg KH

Quoted 2 lines · 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.

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.

Quoted 7 lines

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 8 lines · Kirill Tkhai

Quoted 6 lines · Greg KH

Quoted 2 lines · 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.

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

Quoted 2 lines

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 :)

Quoted 23 lines

Quoted 7 lines

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

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...)

Quoted 9 lines · Greg KH

Quoted 8 lines · Kirill Tkhai

Quoted 6 lines · Greg KH

Quoted 2 lines · 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.

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

Quoted 6 lines

Quoted 2 lines

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?

Quoted 34 lines

Quoted 23 lines

Quoted 7 lines

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

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...)

Quoted 3 lines

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.

Quoted 13 lines · Kirill Tkhai

Quoted 12 lines · Greg KH

Quoted 10 lines · Kirill Tkhai

Quoted 6 lines · Greg KH

Quoted 2 lines · 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.

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.

Quoted 5 lines

Quoted 3 lines

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?

Quoted 4 lines

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?

Quoted 34 lines

Quoted 34 lines

Quoted 23 lines

Quoted 7 lines

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

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...)

Quoted 8 lines

Quoted 3 lines

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?

Quoted 1 line

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?

Quoted 18 lines · Greg KH

Quoted 17 lines · Kirill Tkhai

Quoted 15 lines · Greg KH

Quoted 10 lines · Kirill Tkhai

Quoted 6 lines · Greg KH

Quoted 2 lines · 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.

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 :)

Quoted 3 lines

Quoted 1 line

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.

Quoted 6 lines

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.

Quoted 12 lines · Greg KH

Quoted 11 lines · Kirill Tkhai

Quoted 10 lines · Greg KH

Quoted 9 lines · Kirill Tkhai

Quoted 8 lines · Greg KH

Quoted 5 lines · Kirill Tkhai

Quoted 2 lines

 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.

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

 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.)

Quoted 6 lines

Quoted 6 lines

 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?

Quoted 6 lines

 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.

Quoted 4 lines · Kirill Tkhai

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.)

Quoted 7 lines

Quoted 6 lines

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?

Quoted 6 lines

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.

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

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.

Quoted 2 lines · 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.

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