Backports Archive on lore.kernel.org
 help / color / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Christoph Hellwig <hch@lst.de>,
	Brendan Higgins <brendanhiggins@google.com>
Cc: Cristina Moraru <cristina.moraru09@gmail.com>,
	"vegard.nossum@gmail.com" <vegard.nossum@gmail.com>,
	Valentin Rothberg <valentinrothberg@gmail.com>,
	Hannes Reinecke <hare@suse.de>, Sam Ravnborg <sam@ravnborg.org>,
	Michal Marek <mmarek@suse.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Tom Gundersen <teg@jklm.no>, Kay Sievers <kay@vrfy.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	backports@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"rafael.j.wysocki" <rafael.j.wysocki@intel.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Takashi Iwai <tiwai@suse.de>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	Hauke Mehrtens <hauke@hauke-m.de>,
	Paul Bolle <pebolle@tiscali.nl>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Alexey Khoroshilov <khoroshilov@ispras.ru>,
	Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Laurence Oberman <loberman@redhat.com>,
	Johannes Thumshirn <jthumshirn@suse.de>,
	Tejun Heo <tj@kernel.org>,
	Jej B <James.Bottomley@hansenpartnership.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	danijons@student.chalmers.se, Andrzej Wasowski <wasowski@itu.dk>
Subject: Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute
Date: Tue, 5 Feb 2019 16:07:46 -0600
Message-ID: <CAB=NE6UfkNN5kES6QmkM-dVC=HzKsZEkevH+Y3beXhVb2gC5vg@mail.gmail.com> (raw)
In-Reply-To: <20160825201919.GE3296@wotan.suse.de>

On Thu, Aug 25, 2016 at 2:19 PM Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>
> On Thu, Aug 25, 2016 at 09:43:13AM +0200, Christoph Hellwig wrote:
> > The idea seems useful, but I reallt don't like the 'reverse-engineering'
> > approach.
> >
> > If we want to this properly from the ground up we should just split out
> > our CONFIG_ SYMBOLS into
> >
> > MODULE_* - builds exactly one module (tristate, or maybe also as a built-in
> > only one, then like a bool)
> >
> > CONFIG_* - just bool, MODULE_ may depend on it, too.
>
> Curious what does the split buy us if the real meaningful input is the value
> assigned to the config ? Ie, MODULE_FOO=m would be the modules we want to
> check for.

Also, unless you have kernel sources I don't think you could still
easily infer which MODULE_* config option enabled the module, could
you? And this was one of the original goals with this patch set. I
still think extending the modinfo section would be needed to allow
udevadm info to easily extract the information, no?

> > The other nice thing is that we could probably fold most of the Makefiles
> > into Kconfig using that methods as well, by listing the objectes required
> > for a module, e.g.
>
> OK If the Kconfig file has the objects listed I can see the gain of using
> Kconfig then to more easily map out to a symbol, given doing this on Makefiles
> is not straight forward.
>
> > module NVME_TARGET
> >       tristate "NVMe Target support"
> >       depends on BLOCK
> >       depends on CONFIGFS_FS
> >       name nvmet
> >       objects core.o configfs.o admin-cmd.o io-cmd.o fabrics-cmd.o
> >       objects discovery.o
> >
> > module NVME_TARGET_LOOP
> >       tristate "NVMe loopback device support"
> >       depends on BLK_DEV_NVME
> >       depends on NVME_TARGET
> >       select NVME_FABRICS
> >       select SG_POOL
> >       name nvme-loop
> >       objects loop.o
>
> I can see a huge win of having a direct specification that provides as a
> feature two way mapping from CONFIG <--> module (objects) and backwards again
> easily and clearly without hacks, specially if upon boot then we can then
> provide the precise kernel configuration you need, for both built-in and
> modules. The above could help with modules -- for built-in reverse mapping
> we'd need something else, perhaps a configurable option to keep tabs on
> inits called with associated configs.
>
> The above would be a pretty intrusive change though, in comparison to
> Cristina's original approach.

I think this is the biggest issue so far, and that we have no code to
showcase for it. Meanwhile pegging at least a kconfig symbol to
modinfo for at least a lot of modules would help considerably for
other use cases mentioned.

> The reverse-engineering object --> config
> aspect of her work and of the old scripts/kconfig/streamline_config.pl
> explains why it was hard. I'd be curious to learn of other gains possible
> other than those listed so far, if we had this.
>
> Re-iterating gains of having a simple two way CONFIG <--> module (objects)
> mapping (following the above proposal now):
>
> a) When optimizing build requirements for a kernel for a system.
>    That is you boot into a distro kernel and then want to build
>    a slim kernel only with sensible kernel configuration options.
>
> b) When you are on a distribution kernel but the distribution
>    kernel provided lacks hardware support for your device, you
>    may either want to upgrade the full kernel in which case you
>    want to do a) or -- you may want to just a backports release
>    which provides just the modules you need, you'd use it on top
>    of the distribution kernel.
>
> c) Having the mapping in sysfs would allow to simplify
>    streamline_config.pl avoid parsing Makefiles in perl. (From Michal)

It took me a while to recall where this was and why after 3 years of
not following up on this thread. So in case others fall into the same
boat, the sysfs gain here is that the modinfo section could be
readable then on any module's:

/sys/module/e1000/section/kconfig_symb

> d) Fold most of the Makefiles into Kconfig
>
> In retrospect c) still seems related to a) as we'd do away with
> the hacks completely needed by streamline_config.pl, a) can be
> augmented if we figure out a built-in solution as well.
>
> d) Just seems like collateral of a more precise mapping than
> what a Makefile provides. Anything else ?

In lieu of no Luke Skywalker, if you will, for a large kconfig revamp
on this, I'm inclined to believe *at least* having some kconfig_symb
exposed for some modules is better than nothing. Christoph are you
totally opposed to this effort until we get a non-reverse engineered
effort in place? It just seems like an extraordinary amount of work
and I'm not quite sure who's volunteering to do it.

Other stakeholders may benefit from at least having some config -->
module mapping for now. Not just backports or building slimmer
kernels.

 Luis
--
To unsubscribe from this list: send the line "unsubscribe backports" in

  reply index

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1471462023-119645-1-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 17:55 ` Luis R. Rodriguez
2016-08-19  9:07   ` Michal Marek
2016-08-22 19:48     ` Cristina-Gabriela Moraru
2016-08-23 21:32     ` Luis R. Rodriguez
2016-08-24 11:05       ` Michal Marek
2016-08-24 16:33         ` Luis R. Rodriguez
2016-08-24 17:31           ` Naveen Kumar
2016-08-22 19:35   ` Cristina-Gabriela Moraru
2016-08-23 19:17     ` Luis R. Rodriguez
2016-08-25  7:43   ` Christoph Hellwig
2016-08-25  8:00     ` Johannes Berg
2016-08-25 19:51       ` Luis R. Rodriguez
2016-08-25  8:41     ` Michal Marek
2016-08-25 20:19     ` Luis R. Rodriguez
2019-02-05 22:07       ` Luis Chamberlain [this message]
2019-06-26 22:21         ` Luis Chamberlain
2019-06-27  4:50           ` Christoph Hellwig
2019-06-28 18:40             ` Luis Chamberlain
2019-06-29  8:42               ` Greg Kroah-Hartman
2019-07-02 20:51                 ` Luis Chamberlain
2019-07-03  7:40                   ` Greg Kroah-Hartman
2019-07-03 16:50                     ` Luis Chamberlain
2019-07-03 18:57                       ` Greg Kroah-Hartman
2019-07-03 22:25                         ` Luis Chamberlain
2019-07-11 23:07                           ` Brendan Higgins
2019-07-11 23:22                             ` Luis Chamberlain
2019-07-03 12:16               ` Enrico Weigelt, metux IT consult
2019-07-03 17:35                 ` Luis Chamberlain
2019-07-03 19:31                   ` Enrico Weigelt, metux IT consult
2019-07-03 22:42                     ` Luis Chamberlain
2019-07-11 23:27                       ` Brendan Higgins
2019-07-13 14:44                         ` Enrico Weigelt, metux IT consult
     [not found] ` <1471462023-119645-3-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 18:10   ` [RFC PATCH 2/5] Add CONFIG symbol to module as compilation parameter Luis R. Rodriguez
2016-08-18 18:55     ` Luis R. Rodriguez
2016-08-20 15:11     ` Cristina-Gabriela Moraru
2016-08-23 19:07       ` Luis R. Rodriguez
     [not found] ` <1471462023-119645-2-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 18:22   ` [RFC PATCH 1/5] Add generation of Module.symb in streamline_config Luis R. Rodriguez
2016-08-18 18:32     ` Luis R. Rodriguez
     [not found]     ` <CAGZ2q2xi9Uy-ye387=mWhy_fOEJBC593Nos7fH027m-_ZdoOXA@mail.gmail.com>
2016-08-20 14:49       ` Cristina-Gabriela Moraru
2016-08-23 19:00       ` Luis R. Rodriguez
     [not found] ` <1471462023-119645-4-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 18:30   ` [RFC PATCH 3/5] Trigger Module.ksymb generation in Makefile Luis R. Rodriguez
     [not found] ` <1471462023-119645-5-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 18:59   ` [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb module attribute Luis R. Rodriguez
2016-08-20 15:16     ` Cristina-Gabriela Moraru
2016-08-23 19:10       ` Luis R. Rodriguez
     [not found] ` <1471462023-119645-6-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 19:02   ` [RFC PATCH 5/5] Add kconf_symb as kernel " Luis R. Rodriguez

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='CAB=NE6UfkNN5kES6QmkM-dVC=HzKsZEkevH+Y3beXhVb2gC5vg@mail.gmail.com' \
    --to=mcgrof@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=backports@vger.kernel.org \
    --cc=brendanhiggins@google.com \
    --cc=cristina.moraru09@gmail.com \
    --cc=danijons@student.chalmers.se \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=hauke@hauke-m.de \
    --cc=hch@lst.de \
    --cc=johannes@sipsolutions.net \
    --cc=jthumshirn@suse.de \
    --cc=kay@vrfy.org \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=loberman@redhat.com \
    --cc=martin.petersen@oracle.com \
    --cc=mchehab@osg.samsung.com \
    --cc=mmarek@suse.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=pebolle@tiscali.nl \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rusty@rustcorp.com.au \
    --cc=sam@ravnborg.org \
    --cc=sathya.prakash@broadcom.com \
    --cc=teg@jklm.no \
    --cc=tiwai@suse.de \
    --cc=tj@kernel.org \
    --cc=tytso@mit.edu \
    --cc=valentinrothberg@gmail.com \
    --cc=vegard.nossum@gmail.com \
    --cc=wasowski@itu.dk \
    /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

Backports Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/backports/0 backports/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 backports backports/ https://lore.kernel.org/backports \
		backports@vger.kernel.org backports@archiver.kernel.org
	public-inbox-index backports

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.backports


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