linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.de.marchi@gmail.com>
To: Kirill Tkhai <tkhai@yandex.ru>, Greg KH <gregkh@linuxfoundation.org>
Cc: Michal Marek <mmarek@suse.cz>,
	arnd@arndb.de, linux-kbuild@vger.kernel.org,
	lkml <linux-kernel@vger.kernel.org>, oleg <oleg@redhat.com>,
	grant.likely@secretlab.ca, ebiederm@xmission.com,
	Andrew Morton <akpm@linux-foundation.org>,
	ktkhai@parallels.com, sam@ravnborg.org,
	linux-modules <linux-modules@vger.kernel.org>
Subject: Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules
Date: Tue, 16 Sep 2014 12:40:16 -0300	[thread overview]
Message-ID: <CAKi4VAL5q=ptxeOE0OjG69EdjAXohPSN1ipVUipK+9JPahEE0g@mail.gmail.com> (raw)
In-Reply-To: <20140914185631.GB18506@kroah.com>

On Sun, Sep 14, 2014 at 3:56 PM, Greg KH <gregkh@linuxfoundation.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

  parent reply	other threads:[~2014-09-16 15:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-14 10:18 [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules Kirill Tkhai
2014-09-14 10:18 ` [PATCH 1/3] kbuild: Make targets names tree-wide unique on x86 Kirill Tkhai
2014-09-14 15:57   ` Peter Foley
2014-09-14 18:09     ` Kirill Tkhai
2014-09-14 10:18 ` [PATCH 2/3] core: Save list of built-in drivers names Kirill Tkhai
2014-09-14 10:19 ` [PATCH 3/3] core: create /proc/built-in file to show the list of built-in drivers Kirill Tkhai
2014-09-14 15:38 ` [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules Greg KH
2014-09-14 17:27   ` Oleg Nesterov
2014-09-14 17:57     ` Kirill Tkhai
2014-09-14 18:12       ` Richard Weinberger
2014-09-14 18:58         ` Kirill Tkhai
2014-09-14 20:00       ` Oleg Nesterov
2014-09-14 17:31   ` Kirill Tkhai
2014-09-14 17:39     ` Greg KH
2014-09-14 18:05       ` Kirill Tkhai
2014-09-14 18:13         ` Greg KH
2014-09-14 18:35           ` Kirill Tkhai
2014-09-14 18:56             ` Greg KH
2014-09-15 11:50               ` Kirill Tkhai
2014-09-16 15:40               ` Lucas De Marchi [this message]
2014-09-15  9:17     ` Michal Marek
2014-09-15  9:12   ` Michal Marek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKi4VAL5q=ptxeOE0OjG69EdjAXohPSN1ipVUipK+9JPahEE0g@mail.gmail.com' \
    --to=lucas.de.marchi@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=ebiederm@xmission.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@linuxfoundation.org \
    --cc=ktkhai@parallels.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=oleg@redhat.com \
    --cc=sam@ravnborg.org \
    --cc=tkhai@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).