Linux-Modules Archive on lore.kernel.org
 help / Atom feed
From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Alexey Gladkov <gladkov.alexey@gmail.com>
Cc: Jessica Yu <jeyu@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	linux-api@vger.kernel.org, linux-modules@vger.kernel.org,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Lucas De Marchi <lucas.de.marchi@gmail.com>
Subject: Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
Date: Mon, 29 Apr 2019 12:28:41 +0900
Message-ID: <CAK7LNASzvNf+RwXtdHAcmWXQx9QniLiiJVxe08jHh51KsahOcA@mail.gmail.com> (raw)
In-Reply-To: <20190426152904.GO9023@dhcp129-178.brq.redhat.com>

On Sat, Apr 27, 2019 at 12:29 AM Alexey Gladkov
<gladkov.alexey@gmail.com> wrote:
>
> On Fri, Apr 19, 2019 at 12:03:50PM +0900, Masahiro Yamada wrote:
> > On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu <jeyu@kernel.org> wrote:
> > >
> > > +++ Masahiro Yamada [19/04/19 00:26 +0900]:
> > > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <jeyu@kernel.org> wrote:
> > > >>
> > > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]:
> > > >> >On Sat, Apr 6, 2019 at 9:15 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.
> > > >> >>
> > > >> >> 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.
> > > >> >>
> > > >> >> Proposal:
> > > >> >>
> > > >> >> The proposed patch does not remove .modinfo section with module
> > > >> >> information from the vmlinux at the build time and saves it into a
> > > >> >> separate file after kernel linking. So, the kernel does not increase in
> > > >> >> size and no additional information remains in it. Information is stored
> > > >> >> in the same format as in the separate modules (null-terminated string
> > > >> >> array). Because the .modinfo section is already exported with a separate
> > > >> >> modules, we are not creating a new API.
> > > >> >>
> > > >> >> It can be easily read in the userspace:
> > > >> >>
> > > >> >> $ tr '\0' '\n' < kernel.builtin
> > > >> >> ext4.softdep=pre: crc32c
> > > >> >> ext4.license=GPL
> > > >> >> ext4.description=Fourth Extended Filesystem
> > > >> >> ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
> > > >> >> ext4.alias=fs-ext4
> > > >> >> ext4.alias=ext3
> > > >> >> ext4.alias=fs-ext3
> > > >> >> ext4.alias=ext2
> > > >> >> ext4.alias=fs-ext2
> > > >> >> md_mod.alias=block-major-9-*
> > > >> >> md_mod.alias=md
> > > >> >> md_mod.description=MD RAID framework
> > > >> >> md_mod.license=GPL
> > > >> >> md_mod.parmtype=create_on_open:bool
> > > >> >> md_mod.parmtype=start_dirty_degraded:int
> > > >> >> ...
> > > >> >>
> > > >> >> v2:
> > > >> >>  * Extract modinfo from vmlinux.o as suggested by Masahiro Yamada;
> > > >> >>  * Rename output file to kernel.builtin;
> > > >> >
> > > >> >Sorry, I do not get why you renamed
> > > >> >"kernel.builtin.modinfo" to "kernel.builtin".
> > > >> >
> > > >> >If you drop "modinfo", we do not understand
> > > >> >what kind information is contained in it.
> > > >> >
> > > >> >I think "kernel" and "builtin" have
> > > >> >a quite similar meaning here.
> > > >> >
> > > >> >How about "builtin.modinfo" for example?
> > > >> >
> > > >> >
> > > >> >It is shorter, and it is clear enough
> > > >> >that it contains module_info.
> > > >>
> > > >> I agree that the name kernel.builtin is unclear in what kind of
> > > >> information it contains. Apologies for not having clarified this in
> > > >> the previous review.
> > > >>
> > > >> Since kbuild already produces "modules.order" and "modules.builtin"
> > > >> files, why not just name it "modules.builtin.modinfo" to keep the
> > > >> names consistent with what is already there?
> > > >
> > > >
> > > >Is it consistent?
> > > >
> > > >If we had "modules.order" and "modules.builtin.order" there,
> > > >I would agree with "modules.builtin.modinfo",
> > > >and also "modules.alias" vs "modules.builtin.alias".
> > > >
> > > >
> > > >We already have "modules.builtin", and probably impossible
> > > >to rename it, so we cannot keep consistency in any way.
> > > >
> > > >
> > > >"modules.builtin" is a weird name since
> > > >it actually contains "order", but its extension
> > > >does not express what kind of information is in it.
> > > >Hence, I doubt "modules.builtin" is a good precedent.
> > > >
> > > >IMHO, "modules" and "builtin" are opposite
> > > >to each other. "modules.builtin" sounds iffy to me.
> > >
> > > I've always interpreted "modules.builtin" to mean "this is a list of
> > > modules that have been built-in into the kernel", no? So I thought the
> > > name made sense.
> >
> > OK, I see.
> >
> > > But you are the maintainer, so I do not have a strong
> > > opinion on this either way :-)
> >
> > My idea was to use
> > 'modules.<file-type>'  vs  'builtin.<file-type>'
> > instead of
> > 'modules.<file-type>'  vs  'modules.builtin.<file-type>'
> >
> > I am slightly in favor of the former
> > since it is shorter and
> > (I hope) still clear enough.
> >
> > If this naming is not nice for external projects such as kmod,
> > please speak up.
> >
> >
> > (BTW, I am thinking of renaming 'modules.builtin' into 'builtin.order'
> > for kbuild internal. We cannot change that for the installation area, though.)
>
> Since there were no other suggestions, how can I better name the file ?
> modules.builtin.modinfo or just builtin.modinfo ? I personally like the
> first one more.


Either is fine.

Please put it in Documentation/dontdiff too.

Thanks.



-- 
Best Regards
Masahiro Yamada

      reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-06 12:14 Alexey Gladkov
2019-04-18 11:10 ` Masahiro Yamada
2019-04-18 13:52   ` Jessica Yu
2019-04-18 14:36     ` Lucas De Marchi
2019-04-18 15:26     ` Masahiro Yamada
2019-04-18 15:36       ` Jessica Yu
2019-04-19  3:03         ` Masahiro Yamada
2019-04-26 15:29           ` Alexey Gladkov
2019-04-29  3:28             ` Masahiro Yamada [this message]

Reply instructions:

You may reply publically 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=CAK7LNASzvNf+RwXtdHAcmWXQx9QniLiiJVxe08jHh51KsahOcA@mail.gmail.com \
    --to=yamada.masahiro@socionext.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gladkov.alexey@gmail.com \
    --cc=glebfm@altlinux.org \
    --cc=jeyu@kernel.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=linux-modules@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=michal.lkml@markovi.net \
    --cc=rusty@rustcorp.com.au \
    /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

Linux-Modules Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-modules/0 linux-modules/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-modules linux-modules/ https://lore.kernel.org/linux-modules \
		linux-modules@vger.kernel.org linux-modules@archiver.kernel.org
	public-inbox-index linux-modules


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-modules


AGPL code for this site: git clone https://public-inbox.org/ public-inbox