linux-kernel - Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAKi4VAL5q=ptxeOE0OjG69EdjAXohPSN1ipVUipK+9JPahEE0g@mail.gmail.com>
Date:	Tue, 16 Sep 2014 12:40:16 -0300
From:	Lucas De Marchi <lucas.de.marchi@...il.com>
To:	Kirill Tkhai <tkhai@...dex.ru>,
	Greg KH <gregkh@...uxfoundation.org>
Cc:	Michal Marek <mmarek@...e.cz>, arnd@...db.de,
	linux-kbuild@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	oleg <oleg@...hat.com>, grant.likely@...retlab.ca,
	ebiederm@...ssion.com, Andrew Morton <akpm@...ux-foundation.org>,
	ktkhai@...allels.com, sam@...nborg.org,
	linux-modules <linux-modules@...r.kernel.org>
Subject: Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules

On Sun, Sep 14, 2014 at 3:56 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Sun, Sep 14, 2014 at 10:35:58PM +0400, Kirill Tkhai wrote:
>>
>> 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.)


Yeah. And let me add that kmod treats /proc/modules as deprecated.
It's way nicer to get the information from sysfs. See
https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/tree/README#n116

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

you're probably using ancient userspace. kmod checks the
modules.builtin file generated by the kernel buildsys so "modprobe
buitin-module" doesn't return an error.

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

Yeah... and if you do this way you may not even bother about the
module itself. See the output of "kmod static-nodes". These nodes are
created by init even if the module itself is not loaded. The right
module will be loaded when the node is first accessed. And that
includes the "loop" module you mention.

$ kmod static-nodes | grep -A3 loop
Module: loop
        Device node: /dev/loop-control
                Type: character device
                Major: 10
                Minor: 237

-- 

Lucas De Marchi
--
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/