linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Alexey Gladkov <gladkov.alexey@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	linux-api@vger.kernel.org,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Lucas De Marchi <lucas.de.marchi@gmail.com>
Subject: Re: [RESEND PATCH v1] moduleparam: Save information about built-in modules in separate file
Date: Wed, 27 Mar 2019 16:40:25 +0100	[thread overview]
Message-ID: <20190327154025.GB23293@linux-8ccs> (raw)
In-Reply-To: <20190326172411.GA15936@Legion-PC.fortress>

+++ Alexey Gladkov [26/03/19 18:24 +0100]:
>On Fri, Mar 22, 2019 at 02:34:12PM +0900, Masahiro Yamada wrote:
>> Hi.
>>
>> (added some people to CC)

(Thanks Masahiro for the CC!)

>>
>> On Fri, Mar 15, 2019 at 7:10 PM Alexey Gladkov <gladkov.alexey@gmail.com> wrote:
>> >
>> > Problem:
>> >
>> > When a kernel module is compiled as a separate module, some important
>> > information about the kernel module is available via .modinfo section of
>> > the module.  In contrast, when the kernel module is compiled into the
>> > kernel, that information is not available.
>>
>>
>> I might be missing something, but
>> vmlinux provides info of builtin modules
>> in /sys/module/.
>
>No. There are definitely not all modules. I have a builtin sha256_generic,
>but I can't find him in the /sys/module.

Yeah, you'll only find builtin modules under /sys/module/ if it has any module
parameters, otherwise you won't find it there. As Masahiro already mentioned,
if a builtin module has any parameters, they would be accessible under /sys/module/.

>> (Looks like currently only module_param and MODULE_VERSION)
>>
>> This patch is not exactly the same, but I see a kind of overwrap.
>> I'd like to be sure if we want this new scheme.
>
>The /sys/module is only for running kernel. One of my use cases is
>to create an initrd for a new kernel.
>
>>
>> > Information about built-in modules is necessary in the following cases:
>> >
>> > 1. When it is necessary to find out what additional parameters can be
>> > passed to the kernel at boot time.
>>
>>
>> Actually, /sys/module/<module>/parameters/
>> exposes this information.
>>
>> Doesn't it work for your purpose?
>
>No, since creating an initrd needs to know all the modalias before
>I get the sysfs for new kernel. Also there are no modalias at all.
>
>> > 2. When you need to know which module names and their aliases are in
>> > the kernel. This is very useful for creating an initrd image.
>> >

Hm, I do see one possible additional use-case for preserving module alias
information for built-in modules - modprobe will currently error (I think,
correct me if I'm wrong) if we try invoking modprobe with an alias of a
built-in module, simply because this information is not in modules.builtin or
modules.alias.

Since kbuild already outputs modules.builtin, I would suggest outputting
something like a modules.builtin.alias file (and I guess maybe a modules.builtin.param
file too if that's deemed useful), in a format that is consumable by kmod/modprobe,
so that modprobing an alias of a built-in module doesn't produce an error. I
think this should be easy to do if we keep and parse the resulting .modinfo for
builtin modules. This is just an idea, opinions welcome. I've added Lucas to CC
in case he has any thoughts.


Thanks,

Jessica


  reply	other threads:[~2019-03-27 15:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-15 10:10 [RESEND PATCH v1] moduleparam: Save information about built-in modules in separate file Alexey Gladkov
2019-03-20  8:54 ` Masahiro Yamada
2019-03-22  5:34 ` Masahiro Yamada
2019-03-26 17:24   ` Alexey Gladkov
2019-03-27 15:40     ` Jessica Yu [this message]
2019-03-27 16:04       ` Alexey Gladkov
2019-03-28 17:56         ` Lucas De Marchi
2019-04-03 11:30         ` Masahiro Yamada
2019-03-28 17:41       ` Lucas De Marchi
2019-03-28 18:45         ` Greg KH
2019-03-28 21:33           ` Dmitry Torokhov
2019-04-03 10:45     ` Masahiro Yamada
2019-04-03 10:48       ` Masahiro Yamada

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=20190327154025.GB23293@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gladkov.alexey@gmail.com \
    --cc=glebfm@altlinux.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=ldv@altlinux.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=michal.lkml@markovi.net \
    --cc=rusty@rustcorp.com.au \
    --cc=yamada.masahiro@socionext.com \
    /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).