Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Andi Kleen <ak@linux.intel.com>
Cc:     gladkov.alexey@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] moduleparam: Save information about built-in modules in separate file
References: <20190306165425.GD14017@MacBook-PC.fortress>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:+ngZPz4f8xkSzaw0K/q7E8D445M=
Date:   Wed, 06 Mar 2019 16:07:03 -0800
In-Reply-To: <20190306165425.GD14017@MacBook-PC.fortress> (Alexey Gladkov's
        message of "Wed, 6 Mar 2019 17:54:25 +0100")
Message-ID: <871s3jv97c.fsf@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain
To:     unlisted-recipients:; (no To-header on input)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Alexey Gladkov <gladkov.alexey@gmail.com> writes:

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

I would just keep it in the vmlinux as a non loadable segment, which
won't make it into bzImage. vmlinux passed around anyways, and
it's easier to handle than extra files, and it already has plenty
of metadata in it.

-Andi