From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92E97C43218 for ; Fri, 26 Apr 2019 15:29:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 63FE52077B for ; Fri, 26 Apr 2019 15:29:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726385AbfDZP3R (ORCPT ); Fri, 26 Apr 2019 11:29:17 -0400 Received: from monster.unsafe.ru ([5.9.28.80]:41248 "EHLO mail.unsafe.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726172AbfDZP3P (ORCPT ); Fri, 26 Apr 2019 11:29:15 -0400 Received: from dhcp129-178.brq.redhat.com (nat-pool-brq-t.redhat.com [213.175.37.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.unsafe.ru (Postfix) with ESMTPSA id 05270C61824; Fri, 26 Apr 2019 15:29:06 +0000 (UTC) Date: Fri, 26 Apr 2019 17:29:04 +0200 From: Alexey Gladkov To: Masahiro Yamada Cc: Jessica Yu , Linux Kernel Mailing List , Linux Kbuild mailing list , linux-api@vger.kernel.org, linux-modules@vger.kernel.org, "Kirill A . Shutemov" , Gleb Fotengauer-Malinovskiy , "Dmitry V. Levin" , Michal Marek , Dmitry Torokhov , Rusty Russell , Lucas De Marchi Subject: Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file Message-ID: <20190426152904.GO9023@dhcp129-178.brq.redhat.com> References: <20190406121447.GB4047@localhost.localdomain> <20190418135238.GA5626@linux-8ccs> <20190418153611.GB5626@linux-8ccs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 19, 2019 at 12:03:50PM +0900, Masahiro Yamada wrote: > On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu wrote: > > > > +++ Masahiro Yamada [19/04/19 00:26 +0900]: > > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu wrote: > > >> > > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]: > > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov 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.' vs 'builtin.' > instead of > 'modules.' vs 'modules.builtin.' > > 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. -- Rgrds, legion