public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Oleg Verych <olecom@flower.upol.cz>,
	kbuild devel <kbuild-devel@lists.sourceforge.net>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/RFT] kbuild: save ARCH & CROSS_COMPILE
Date: Tue, 9 Oct 2007 08:01:04 +0200	[thread overview]
Message-ID: <20071009060104.GA22087@uranus.ravnborg.org> (raw)
In-Reply-To: <20071008215316.6e186b89.randy.dunlap@oracle.com>

> > 2) We need to share much more Kconfig* between the individual architectures
> >    First step is to let all arch's use drivers/Kconfig
> 
> 2) isn't terribly difficult, just takes some time and willingness
> of $arch maintainers to some changes, but please explain a bit more
> why it is needed...?

A prerequisite for moving ARCH selection to Kconfig is that we
read in all Kconfig files for all architectures.
To do so efficient we should avoind including the same Kconfig
file for each architecture which is obviously the case today.

The efficiency comes both with respect to reading the files but
also memory consumption. If we read in drivers/Kconfig only once
then we will avoid some duplication compared to reading drivers/Kconfig
once for each architecture.

The structure we should aim for is something like a top-level
Kconfig file that pull in relevant parts from the kernel tree
and where the arch Kconfig only pull in additional Kconfig files
from that arch.

When we get this far we will have a more logical structure
in the Kconfig file and their distribution.

But the showstopper is the part with choice value that cannot have more
than a single prompt so when we have the same choice value
used in two arch Kconfig files then kconfig will warn and the
choice will do the wrong thing.
I never took a deeper look at this - I seem to get distracted each
time I try to understand all the inner details of the kconfig
use of data structures.

	Sam


  parent reply	other threads:[~2007-10-09  5:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-08 20:02 [RFC/RFT] kbuild: save ARCH & CROSS_COMPILE Sam Ravnborg
2007-10-08 20:50 ` Oleg Verych
2007-10-09  4:17   ` Sam Ravnborg
2007-10-09  4:53     ` Randy Dunlap
2007-10-09  5:28       ` Randy Dunlap
2007-10-09  6:01       ` Sam Ravnborg [this message]
2007-10-09  8:37     ` Oleg Verych
2007-10-08 21:12 ` Adrian Bunk
2007-10-08 21:20   ` Giacomo Catenazzi
2007-10-09  6:03   ` Sam Ravnborg
2007-10-09  9:54     ` Adrian Bunk
2007-10-09  9:39 ` Andi Kleen
2007-10-09 10:00   ` Sam Ravnborg
2007-10-09 11:08     ` Andi Kleen
2007-10-09 14:09     ` Jeff Dike
2007-10-09 16:34       ` Sam Ravnborg
2007-10-09 17:44         ` Jeff Dike
2007-10-10  2:35 ` Kristoffer Ericson

Reply instructions:

You may reply publicly 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=20071009060104.GA22087@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=kbuild-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olecom@flower.upol.cz \
    --cc=randy.dunlap@oracle.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox