Re: What is listed in /sys/module?

[Jean Delvare]

Hi Rusty,

Thanks for the fast and helpful reply.

On Thu, 30 May 2013 11:53:10 +0530, anish singh wrote:
> On Thu, May 30, 2013 at 6:24 AM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> > Jean Delvare <khali@xxxxxxxxxxxx> writes:
> >> Hi Greg, Rusty,
> >>
> >> I have a question related to /sys/module and can't seem to find the
> >> answer by myself so I hope you can explain.
> >>
> >> I noticed that /sys/module contains more than /proc/modules. At first I
> >> thought that any potentially modular piece of code would show up
> >> in /sys/module, so /sys/module would include both actual modules and
> >> "built-in modules".
> >>
> >> However I then noticed that some built-in modules do _not_ show up
> >> in /sys/module. For example, I have USB and I2C core support built into
> >> my 3.9.4 kernel, /sys/module/usbcore exists but /sys/module/i2c_core
> >> does not. CONFIG_SENSORS_W83795=y did not give me /sys/module/w83795
> >> either.
> >
> > Yes.  /sys/module entries are created for builtin "modules" with
> > parameters.  This is because, the module names are discovered by

Apparently having a module version defined is enough as well. For
example xz_dec has no parameters, but it has a version,
and /sys/module/xz_dec is created when built-in. The code for that is
in version_sysfs_builtin().

> So documentation is wrong about that.

It is incomplete, as it doesn't mention any condition
to /sys/module/MODULENAME being created, yes. I'll send a patch -
unless someone has a plan to fix the issue itself.

> > scouring the parameters: see param_sysfs_builtin().
> >
> > Two things to note about builtin modules:
> >
> > 1) There is nothing other than parameters in /sys/module/, except a
> >    uevent which is used for managing the parameters.  So, without
> >    parameters, it would be an empty directory.
> >
> > 2) We actually do generate a list of builtin modules these days, called
> >    modules.builtin.  So we could generate sysfs dirs from this.
>
> As I understand modules.builtin is the output of the kernel compilation.
> So if we want to make /sys/module consistent then this file needs to
> be parsed by kernel and corresponding sysfs created but what is the

I don't know what you have in mind exactly, but I don't think the
kernel is ever going to parse a user-space file (which may or may not
be available at run-time, BTW.)

Using include/config/tristate.conf directly seems impossible as well,
as the kernel code has no way to look-up the module name from the
Kconfig symbol name - only the build system knows it.

So any approach based on modules.builtin or
include/config/tristate.conf is going to be very tricky, I'm afraid. It
might be easier to create a dummy section for built-in modules. This
could be added to module_init(), except that some modules use
postcore_initcall() or some such instead. Or maybe we have to create a
dedicated call for it, but that would be touching a huge number of
files - unless we make it optional. I can't think of a simple and clean
solution, I'm afraid.

> point of creating just the sysfs without having any parameters information
> which is why this /sys/module exists in the first place right?

My question was motivated by work I'm doing on the sensors-detect
script. The purpose of that script is to tell the user which modules
he/she should load to get hardware monitoring running on his/her
system. The script has to load some modules for the detection itself
(e.g. cpuid, i2c-dev, SMBus controller drivers) and outputs a list of
drivers which should be loaded by the user (but the script itself does
not load them.)

Each of the drivers in question can be completely missing, or built-in,
or built as a module but not loaded, or built as a module and loaded.
In order to make the script as user-friendly as possible, we have to
handle each case properly. If the driver is missing, we want to tell
the user that we can't do the detection completely (if the driver was
needed for probing) or he/she won't be able to make full use of the
hardware (if the driver was needed for run-time.) If the driver is
built-in or already loaded module, then all is fine, we don't have to
load it (for probing) nor to tell the user to do it (for run-time.) If
the driver is modular, we have to load and then unload it (for probing)
or tell the user to do so (for run-time.) So we have 4 cases to handle:

1* Driver missing
2* Driver built-in
3* Module not loaded
4* Module loaded

Case 4 is the easy one, we just look at /proc/modules. But having no
way to tell if a given driver is built-in, makes it impossible to
distinguish between cases 1, 2 and 3. Of course we can try to load the
module anyway and see what happens, but then we have no way to tell a
harmless failure (driver build-in) from a harmful one (driver missing).
It is also harder (although not impossible) to cleanly unload the
modules afterward (we want to rmmod only drivers we successfully loaded
ourselves.)

That problem can be solved by parsing /lib/modules/$(uname -r)/modules.builtin
from sensors-detect directly. Thanks a lot for the suggestion, I had
not considered it. It should work just fine so I'll implement that. And
it will work for all kernels which have this file. I don't know when
we started creating it exactly, apparently since kernel version 2.6.33.

Additionally, when some hwmon drivers are already loaded, this prevents
us from doing the hardware detection. In that case we still try to tell
the user what hardware monitoring device he/she has, and for that we
need to look-up the module name from the kernel device name. Getting
the driver name from the device name always works, but getting the
module name (which may differ from the driver name) not always: it
works fine for modular drivers as they have a "module" link
to /sys/module/$module, but the link is missing if /sys/module/$module
doesn't exist (built-in driver with no parameter and no version.)

I have no solution for that second problem, until /sys/module/$module
is created unconditionally for all built-in drivers.

> > If you want to make it consistent, I look forward to your patch!
>
> I would be interested here.

I have no immediate idea how to implement that, sorry :(

Thanks,
-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/