Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp726803ybb; Thu, 28 Mar 2019 10:58:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwqUQUfmGkCtWoYWtneL5MWOg8i6NkjVBVpyMMClKgR4wJvmblauL1+gj0KwWuhnfKKqWrK X-Received: by 2002:a62:4115:: with SMTP id o21mr41281775pfa.153.1553795901061; Thu, 28 Mar 2019 10:58:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553795901; cv=none; d=google.com; s=arc-20160816; b=Ctw99yP7SNq4YXekhDXZvT645ZsZSA8O6dOK2w/67E76n8imVKjdiob6pWALVd9JtE QcGGtXU35hB4Le2O9mlhjsGK+wFshdPQtwDOi1Ba3eAyYC6KoG+ri0Hq5kZ+tdx34XI2 Bl9wY9JCDmYIRNki2nVB3LEfPnVjiMJ6Wg+Xcpuv0mF+Hmrtpz1TLnJ7FNMoxNbEzlLr PMa9LdPZJeQHw0Q3lyqg7alKiEeudQ5uBpZ7TAAgiOM42MoW2vIo4yePYX63gWtMY30J DIgQiZdBcVEakzeM6PsNzJWYj9+2bxCYsUVFxyDw1mGdc0oukifX0m6zcl7u/YlEu30U HHOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=8apiQeGA3kTurrt37zzzVcwTnb6VCI+k72IHTFshpmg=; b=jbY9vPRoyc6bva7Nafv3nvRRAfTmFKdI2t629Tnra6Ss0aVUxmx+dRv7n5g/Lgg+t4 qD3N9YytcTs/T69qn6KA3vRjup9TjGnUq47hnxBuL5jCcOmL+wQJfNfgOMZfA1rFBDb3 eMOBaITSELbq0Qvuaba8VKYZ8jzDG4//IRXul9hobySZmQBgET/QCkcREG2pymEj/IbM iTTWJ5IZ6A85azUY+XLmRhS5oUns8yMDVxi/f5Mk5JbcVXhwNlMLPKvGwzpI3LdmEx0O 7J9n0He3PaEg94e2L23U1eHotnUhY/poI68Jnjudy4Y55H3O4M475xt5Un1iPDPjcKUM AZ1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uTHQ47zZ; 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=pass (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 e10si20804085pgo.404.2019.03.28.10.58.04; Thu, 28 Mar 2019 10:58:21 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uTHQ47zZ; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727463AbfC1R5L (ORCPT + 99 others); Thu, 28 Mar 2019 13:57:11 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:42488 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725849AbfC1R5L (ORCPT ); Thu, 28 Mar 2019 13:57:11 -0400 Received: by mail-wr1-f67.google.com with SMTP id g3so20557400wrx.9; Thu, 28 Mar 2019 10:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8apiQeGA3kTurrt37zzzVcwTnb6VCI+k72IHTFshpmg=; b=uTHQ47zZDeS+Q1g3CEK4DoyQpBCyT9vZLe2nCuxaOuJ6b6xsHzm2tCfijAOlyCxc/2 aR0rhXPGiJF1Jrd4+HIes5KouUzyqoDWip/8a/jB8B7sfgalGXsFHS1UQkX6Mre+0tDv ixsu67gNn8GBQ8KZqd3g9VKU5HrhCHMNAvS89N/z3bg6y4BSLWcRGK59TOPIz3h3VuwQ 2d6nOGqGTIcEQhGexNaswQyD6kOeSiJvPoeoPBCrfwAYWzxBkwBziKNv1vTC088LOTTc 8HsqApAle4arSBVjX42rPeW47sZCQC5T71qc7SCNx282wVeqg3hXv+ImiuG4UCQueda9 khxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8apiQeGA3kTurrt37zzzVcwTnb6VCI+k72IHTFshpmg=; b=thVdpKnU8SbF3jpTU9QPfJty0qvtcOUNs0dNoPhvzSNS3102UYcVlzkqZptoUxs5sB 2UvdEZa7PwUu9srEfkJ8hYGwPDBUH87+rmsEiWhrdjRRUpel0xJeDrVL1CS18jOM98WH wLQtysDxj72NhDc1H8CxAxD/qxwlJlTUBa2JpPzTQcqVYEZdFi64+0w+uXZHVrNgms3U 6HEIo0I4yvuHFjwv/bQXyAC+yB/cjI/KA1fiTR4KyFyX4gAtcuSbk1LPUJuncouAwVHu s22z1TkoIUZ5kzSlZL2RqnXV1xU+P+/uplNq+ETARrkKnPY0Vhzm22FWUnsszoo60f22 LIyA== X-Gm-Message-State: APjAAAWrNdQ/s8r9tClnNOgilzq8cV3evV8i1rPcaeBP/JveH1NEie8i ZTr0AUkYAhuZxP6VNVRowkgrpq4QzOKzjOAZ9HA= X-Received: by 2002:adf:e487:: with SMTP id i7mr28733940wrm.264.1553795828507; Thu, 28 Mar 2019 10:57:08 -0700 (PDT) MIME-Version: 1.0 References: <20190315101013.GN8455@Legion-PC.fortress> <20190326172411.GA15936@Legion-PC.fortress> <20190327154025.GB23293@linux-8ccs> <20190327160440.GE15936@Legion-PC.fortress> In-Reply-To: <20190327160440.GE15936@Legion-PC.fortress> From: Lucas De Marchi Date: Thu, 28 Mar 2019 10:56:57 -0700 Message-ID: Subject: Re: [RESEND PATCH v1] moduleparam: Save information about built-in modules in separate file To: Alexey Gladkov Cc: Jessica Yu , Masahiro Yamada , Michal Marek , Linux Kernel Mailing List , Linux Kbuild mailing list , linux-api@vger.kernel.org, "Kirill A . Shutemov" , Gleb Fotengauer-Malinovskiy , "Dmitry V. Levin" , Dmitry Torokhov , Rusty Russell Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 27, 2019 at 9:04 AM Alexey Gladkov w= rote: > > On Wed, Mar 27, 2019 at 04:40:25PM +0100, Jessica Yu wrote: > > +++ 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 wrote: > > >> > > > >> > Problem: > > >> > > > >> > When a kernel module is compiled as a separate module, some import= ant > > >> > information about the kernel module is available via .modinfo sect= ion 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_gene= ric, > > >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 ment= ioned, > > 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 c= ases: > > >> > > > >> > 1. When it is necessary to find out what additional parameters can= be > > >> > passed to the kernel at boot time. > > >> > > >> > > >> Actually, /sys/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 ali= as > > information for built-in modules - modprobe will currently error (I thi= nk, > > 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.buil= tin or > > modules.alias. > > Yes. Patch for modprobe in my todo list. The reason I didn=E2=80=99t do i= t was > because I wasn=E2=80=99t sure that the file format was final. > > > Since kbuild already outputs modules.builtin, I would suggest outputtin= g > > something like a modules.builtin.alias file (and I guess maybe a module= s.builtin.param > > file too if that's deemed useful), in a format that is consumable by km= od/modprobe, > > so that modprobing an alias of a built-in module doesn't produce an err= or. I > > think this should be easy to do if we keep and parse the resulting .mod= info for > > builtin modules. This is just an idea, opinions welcome. I've added Luc= as to CC > > in case he has any thoughts. > > You don't like kernel.builtin.modinfo ? > > It is much easier to create and it has almost the same format as the > modules. So I think it will be easier to parse in kmod. adding a modules.builtin.alias with the same format of modules.alias means during modprobe we would only need to load one more file to lookup aliases. That doesn't mean the kernel built system should do it though. The same way it's depmod job to create the modules.alias{,.bin}, we could leave this to depmod if it's in fact useful to split the information. I think your version is simple enough and we would get more information that would be useful for modinfo. It would indeed be nice to output something useful in "modinfo ext4". In kmod, I think we would create modules.builtin.modinfo{,.bin} and just add the aliases to modules.alias{,.bin}, This would keep the names consistent with what is already there. thanks Lucas De Marchi > > -- > Rgrds, legion >