Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp772269yba; Fri, 26 Apr 2019 08:30:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqwPbTWDaai20VnANoYtaoP8OzFUBMMyhXscVdFejUs4pVeiz0kTWOFZSp/aocfpb5RBcUoU X-Received: by 2002:a65:50c2:: with SMTP id s2mr44652060pgp.112.1556292625698; Fri, 26 Apr 2019 08:30:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556292625; cv=none; d=google.com; s=arc-20160816; b=WmZqm5sjvMi57FhDZyaPAdV8X71WrTHFIvXCUHfu6gKRfbLgwxfcM1Yc8c9yB2SQq6 gApv6EkaGPE6loC+XRvwycDcWitqzrdWm4n81mBJlbvlWAOyRGm/UYgfeJxkU3XlqBN+ iID8GPtnU630j4z9NoemgiufL/qK9T0fxW8aaxXgapJbH68RaLPaWZly27iRbzlTLppW 1jQsRcYKQ9fQ1cx+Brx9gKRMOZZlwsb0OJmVEyvaawmkVSQgnEoZENrVG/rYv/e1f7br FJA/+TDURn9PUV0GueCLpq3uz6ALJBUF3/VRNXoP9WJIIV1R5hW/nObVJMI2HJeQFLy+ j/xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=oiZTbnvx0HcNglSgEo7KAx1s4JgaWHy4LSiDcHS3EwY=; b=h9bg7+eOeKQiUEIbNY7W/CiB/SmCH3LHJGop+ZykEB66T0xXk6EAYjkMQBGd0kpN5O u3c4aXjndigqW7mnFXVivlkkRa0kWoCcRvBGvuGXrhOo/9p9yjLnjI6rgHK7XfNeEfNY UK4OyotNUffbWgyzJCZTYSYul6uJRoFvsD5/rSxBi4BqSvm4AHXU2RE39QEjGSHxcwKv Ovjsl89mF5C7OSvIIqUuXCtes5JPNP8ti+ONPxZbwYoMTnoul0+elHpCdpT5ulQlpEZ1 1USvfKqnK+KZMZVMxsqSvmwY4u6qnRlitp5ik7NTyrK0xCS+RgvjPyIml7Lmj5RFXMg3 OyEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h11si23722511pgq.198.2019.04.26.08.30.09; Fri, 26 Apr 2019 08:30:25 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726377AbfDZP3Q (ORCPT + 99 others); Fri, 26 Apr 2019 11:29:16 -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