Backports Archive on lore.kernel.org
 help / color / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Brendan Higgins <brendanhiggins@google.com>,
	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>,
	"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>,
	Daniel Jonsson <danijons@student.chalmers.se>,
	Andrzej Wasowski <wasowski@itu.dk>
Subject: Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute
Date: Tue, 2 Jul 2019 20:51:06 +0000
Message-ID: <20190702205106.GR19023@42.do-not-panic.com> (raw)
In-Reply-To: <20190629084257.GA1227@kroah.com>

On Sat, Jun 29, 2019 at 10:42:57AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 28, 2019 at 11:40:22AM -0700, Luis Chamberlain wrote:
> > On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > On Wed, Jun 26, 2019 at 03:21:08PM -0700, Luis Chamberlain wrote:
> > > > On Tue, Feb 5, 2019 at 2:07 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > > > 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.
> > > >
> > > > Christoph, *poke*
> > >
> > > Yes, I'm still totally opposed to a half-backed hack like this.
> > 
> > The solution puts forward a mechanism to add a kconfig_symb where we
> > are 100% certain we have a direct module --> config mapping.
> > 
> > This is *currently* determined when the streamline_config.pl finds
> > that an object has only *one* associated config symbol associated. As
> > Cristina noted, of 62 modules on a running system 58 of them ended up
> > getting the kconfig_symb assigned, that is 93.5% of all modules on the
> > system being tested. For the other modules, if they did want this
> > association, we could allow a way for modules to define their own
> > KBUILD_KCONF variable so that this could be considered as well, or
> > they can look at their own kconfig stuff to try to fit the model that
> > does work. To be clear, the heuristics *can* be updated if there is
> > confidence in alternative methods for resolution. But since it is
> > reflective of our current situation, I cannot consider it a hack.
> > 
> > This implementation is a reflection of our reality in the kernel, and
> > as has been discussed in this thread, if we want to correct the gaps
> > we need to do a lot of work. And *no one* is working towards these
> > goals.
> > 
> > That said, even if you go forward with an intrusive solution like the
> > one you proposed we could still use the same kconfig_symb...
> > 
> > So no, I don't see this as a hack. It's a reflection as to our current
> > reality. And I cannot see how the kconfig_symb can lie or be
> > incorrect. So in fact I think that pushing this forward also makes the
> > problem statement clearer for the future of what semantics needs to be
> > addressed, and helps us even annotate the problematic areas of the
> > kernel.
> > 
> > What negative aspects do you see with this being merged in practice?
> 
> I'm trying to see what the actual problem that you are wanting to solve
> here with this.  What exactly is it?

The problem is that there is no current maping of a module to respective
kconfig symbol.

> Who needs to determine the
> "singular" configuration option that caused a kernel module to be built
> at the expense of all other options?

Folks wanting to slim down their kernel build, and users of backports.

> What can that be used for and who will use it?

Without a mapping there is no clean way to let you slim down your kernel
using a distro kernel as a base, enabling only those things you really
need.

Historically those interested would just have streamline_config.pl at
their disposal, but it isn't perfect. Although Cristina extended
streamline_config.pl, the proper approach here would be to see if the
heuristics in streamline_config.pl which she made use of to map a config
symbol for a module could be written in C. The safe heuristic used is
that for modules where there was only one kconfig symbol associated,
we'd be certain that kconfig symbol was the one needed for that module.

A side benefit is also that by having a modinfo section for the kconfib
symbol we'd have access to it via sysfs, an example is
/sys/module/e1000/section/kconfig_symb, and then streamline_config.pl
could be simplified further by not having to parse Makefiles in perl.
The reason for using a modinfo section also is you could get the
information about configs needed for modules without requiring your
kernel sources, and this information then also becomes available to
augment udevadm for its own hardware db info.

Another set of users of this would be users of backports. For instance
users on distro kernels but their current kernel lacks updated drivers
for one of your devices, and you want to use a backports release, but
just want to build / only the drivers you really need for the release.
Backports then could easily scrape for the sysfs attribute / udevadm db
to let you build and install only the modules you need.

Long term users are developers working on trying to clear up kconfig
semantics. Having a clear indicator in our tree about modules where a
direct mapping was not possible (say with a KBUILD_KCONF definition in
their Makefiles to clarify which config symbol enables it) gives us an
idea of kconfig entries which may be contrived and could use some
clarifications.

  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
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 [this message]
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=20190702205106.GR19023@42.do-not-panic.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