linux-kernel - Re: What is listed in /sys/module?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130530113838.32ff2632@endymion.delvare>
Date:	Thu, 30 May 2013 11:38:38 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	anish singh <anish198519851985@...il.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: What is listed in /sys/module?

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 <khali@...ux-fr.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/