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.
So my questions are:
1* What exactly is supposed to show up in /sys/module?
Documentation/ABI/stable/sysfs-module says:
/sys/module/MODULENAME
The name of the module that is in the kernel. This
module name will show up either if the module is built
directly into the kernel, or if it is loaded as a
dynamic module.
But my tests above contradict this statement.
And more precisely:
2* For what reason do some built-in modules show up in /sys/module and
others do not? Is it a bug?
Thanks,
--
Jean Delvare
Jean Delvare <[email protected]> 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
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.
If you want to make it consistent, I look forward to your patch!
Cheers,
Rusty.
On Thu, May 30, 2013 at 6:24 AM, Rusty Russell <[email protected]> wrote:
> Jean Delvare <[email protected]> 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
So documentation is wrong about that.
> 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
point of creating just the sysfs without having any parameters information
which is why this /sys/module exists in the first place right?
>
> If you want to make it consistent, I look forward to your patch!
I would be interested here.
>
> Cheers,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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 <[email protected]> wrote:
> > Jean Delvare <[email protected]> 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
On Thu, May 30, 2013 at 2:04 PM, Jean Delvare <[email protected]> wrote:
> 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 <[email protected]> wrote:
>> > Jean Delvare <[email protected]> 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.)
Well it does that in case of loading firmwares(loading from userspace)
but that is a different story altogether.
>
> 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
modprobe -l doesn't work?
> 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
Hi Anish,
On Thu, 30 May 2013 14:56:43 +0530, anish singh wrote:
> On Thu, May 30, 2013 at 2:04 PM, Jean Delvare <[email protected]> wrote:
> > 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
>
> modprobe -l doesn't work?
I am reluctant to use an option which is described as "is provided for
backwards compatibility and may go away in future" in the manual page.
Leaving that aside for the sake of the discussion, I can't see how it
solves my problem anyway, as modprobe -l will return nothing in both
case 1 (driver missing) and case 2 (driver built-in) so it won't let me
distinguish between the two.
So I'm going to use modules.builtin.
--
Jean Delvare