ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@sirena.org.uk>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] RFC: Kernel tinification - kernel config reduction
Date: Thu, 14 Aug 2014 17:39:15 +0100	[thread overview]
Message-ID: <20140814163915.GB17528@sirena.org.uk> (raw)
In-Reply-To: <CAMuHMdUH_7KL0KCsZEL91m2YKwBBGTQEcYfQRQsHLcQ8LXHpkQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Thu, Aug 14, 2014 at 09:49:59AM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 14, 2014 at 2:14 AM, Mark Brown <broonie@kernel.org> wrote:

> > allnoconfig is interesting too for similar reasons.

> Yes, but given you can't actually boot it, it usually receives even less care
> than allmodconfig.

Sure, but part of that is a function of people doing coverage working on
it and generally setting standards.

> Plus you have to band-aid various trivia, like
>   - NR_IRQS being zero,
>   - No CPU or platform code included, causing link errors (e.g. head.o is
>     not built on m68k),
>   - ...

That's not the case for all architectures, and TBH it seems like
something that it's reasonable to fix at least in so far as it builds
and links (assuming anyone wants to work on this for the architecutre).

> Furthermore, allnoconfig disables CONFIG_MMU on architectures that support
> nommu, which is less interesting, and thus need a KCONFIG_ALLCONFIG=
> trick (I'd love to have just "make CONFIG_MMU=y allnoconfig" instead).

That'd be nice, yes.

Another thing that's interesting to me is getting the defconfigs up to
the point where they run things like LTP well.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-08-14 16:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13 17:29 Bird, Tim
2014-08-13 18:07 ` Guenter Roeck
2014-08-13 19:53   ` Geert Uytterhoeven
2014-08-13 22:45     ` Guenter Roeck
2014-08-14  0:14       ` Mark Brown
2014-08-14  0:38         ` Guenter Roeck
2014-08-14 15:33           ` Mark Brown
2014-08-14  7:49         ` Geert Uytterhoeven
2014-08-14 16:39           ` Mark Brown [this message]
2014-08-14  7:40       ` Geert Uytterhoeven
2014-08-14  8:50         ` Guenter Roeck
2014-08-14  9:02           ` Geert Uytterhoeven
2014-08-15 11:04             ` Guenter Roeck
2014-08-14 19:57   ` Stefan Hengelein
2014-08-13 19:19 ` josh
2014-08-14 16:30   ` Tim Bird
2014-08-14 17:17     ` Josh Triplett
2014-08-14 16:03 ` Christoph Lameter
2014-08-14 18:54 ` Jan Kara

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=20140814163915.GB17528@sirena.org.uk \
    --to=broonie@sirena.org.uk \
    --cc=geert@linux-m68k.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /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