From: Jesper Juhl <jesper.juhl@gmail.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Paul Mundt <lethal@linux-sh.org>, David Chinner <dgc@sgi.com>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Jan Engelhardt <jengelh@computergmbh.de>,
Matt Mackall <mpm@selenic.com>,
Rene Herman <rene.herman@gmail.com>,
Arjan van de Ven <arjan@infradead.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
William Lee Irwin III <wli@holomorphy.com>,
Bodo Eggert <7eggert@gmx.de>, Jesper Juhl <jesper.juhl@gmail.com>
Subject: [PATCH 0/5] 4KSTACKS no longer a debug feature and doesn't belong in "Kernel hacking".
Date: Sun, 12 Aug 2007 22:50:58 +0200 [thread overview]
Message-ID: <200708122250.58773.jesper.juhl@gmail.com> (raw)
Hi,
The short story:
This is a series of 5 patches to a) lift 4KSTACKS from a debug feature to a
non-debug feature and b) move it out of the Kernel hacking menu and into the
Processor types and features menu and c) make it 'default y', but only
for -mm.
Some more explanation is probably needed, so here's the longer story:
About a month back I posted a RFC patch with the subject
"[PATCH][RFC] 4K stacks default, not a debug thing any more...?" to find out
if I was right in assuming that 4K stacks were no longer considered a debug
only feature and whether or not it would be sensible to make them default.
You can find the head of the thread (100+ mesages) in the lkml.org archives
here: http://lkml.org/lkml/2007/7/11/294 .
Based on the comments in that thread I conclude that 4KSTACKS are not really
considered a debug-only feature any longer, but the time is not right (yet)
to make them the default - and it's certainly not yet the time to get rid of
8K stacks.
In that thread I promised to provide some patches that would lift 4KSTACKS out
of debug-only feature status, which is what the first two patches in this
series do.
I also said I would provide a patch to make 4KSTACKS 'default y' to get more
testing, but restrict that patch to -mm - that's the fifth patch in this
series.
Patches 3 & 4 in this series move the config option out of the Kernel hacking
menu and into Processor types and features - this makes sense once it is no
longer a debug feature and the location is in line with m68knommu (which is
the only arch with this config symbol in addition to i386 & sh) which already
place that symbol there.
Now for a bit on the actual patches. These are the patches in this series :
[PATCH 1/5] 4KSTACKS, remove DEBUG_KERNEL dependency for i386
[PATCH 2/5] 4KSTACKS, remove DEBUG_KERNEL dependency for sh
[PATCH 3/5] 4KSTACKS, move out of Kernel hacking menu (i386)
[PATCH 4/5] 4KSTACKS, move out of Kernel hacking menu (sh)
[PATCH 5/5] 4KSTACKS, make 'default y', -mm patch only.
Andrew; as i386 & -mm maintainer I'm sending you patches 1, 3 & 5 - patches 2
& 4 for Super-H I would like a maintainer ACK on before they go further, so
I'm not Cc'ing you on those (they are on LKML if you want them anyway).
Paul; in the thread I mention above I was focusing 100% on i386. I don't
really know the status of 4KSTACKS on sh, so I'd like your input.
I'm adding a few people from the previous thread to Cc, but far from everyone
as then the Cc list would become too big. For the patches themselves I'm just
sending them to LKML, Andrew & Paul, so pick them up on LKML please (sending
as replies to this mail).
Kind regards,
Jesper Juhl
next reply other threads:[~2007-08-12 20:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-12 20:50 Jesper Juhl [this message]
2007-08-12 20:52 ` [PATCH 1/5] 4KSTACKS, remove DEBUG_KERNEL dependency for i386 Jesper Juhl
2007-08-12 20:53 ` [PATCH 2/5] 4KSTACKS, remove DEBUG_KERNEL dependency for sh Jesper Juhl
2007-08-12 22:44 ` Paul Mundt
2007-08-12 22:49 ` Jesper Juhl
2007-08-12 20:54 ` [PATCH 3/5] 4KSTACKS, move out of Kernel hacking menu (i386) Jesper Juhl
2007-08-12 20:54 ` [PATCH 4/5] 4KSTACKS, move out of Kernel hacking menu (sh) Jesper Juhl
2007-08-12 20:55 ` [PATCH 5/5] 4KSTACKS, make 'default y', -mm patch only Jesper Juhl
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=200708122250.58773.jesper.juhl@gmail.com \
--to=jesper.juhl@gmail.com \
--cc=7eggert@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=dgc@sgi.com \
--cc=jengelh@computergmbh.de \
--cc=jeremy@goop.org \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=rene.herman@gmail.com \
--cc=wli@holomorphy.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