On 14.09.2014 21:39, Greg KH wrote:

On Sun, Sep 14, 2014 at 09:31:58PM +0400, Kirill Tkhai wrote:

quoted

On 14.09.2014 19:38, Greg KH wrote:

quoted

On Sun, Sep 14, 2014 at 02:18:13PM +0400, Kirill Tkhai wrote:

quoted

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?

quoted

quoted

quoted

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