From: Tom Rini <trini@kernel.crashing.org>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] configurable LOG_BUF_SIZE
Date: Mon, 6 Jan 2003 12:15:31 -0700 [thread overview]
Message-ID: <20030106191531.GE796@opus.bloom.county> (raw)
In-Reply-To: <Pine.LNX.4.33L2.0301061104410.15416-100000@dragon.pdx.osdl.net>
On Mon, Jan 06, 2003 at 11:05:49AM -0800, Randy.Dunlap wrote:
> On Mon, 6 Jan 2003, Tom Rini wrote:
>
> | On Mon, Jan 06, 2003 at 10:57:01AM -0800, Randy.Dunlap wrote:
> | > On Mon, 6 Jan 2003, Tom Rini wrote:
> | >
> | > | On Thu, Jan 02, 2003 at 03:09:17PM -0800, Randy.Dunlap wrote:
> | > |
> | > | > This patch to 2.5.54 make LOG_BUF_LEN a configurable option.
> | > | > Actually its shift value is configurable, and that keeps it
> | > | > a power of 2.
> | > |
> | > | Erm, why not just prompt for an int, slightly change the help wording,
> | > | and then just give a default int value directly.
> | > |
> | > | Flexibility is good for everyone.
> | >
> | > Sure, I like that, but LOG_BUF_LEN must be a power of 2 (currently)
> | > and I was trying not to rewrite that circular buffer code, that's all.
> | > However, I will if that's desirable.
> |
> | I actually meant prompting for the shift value itself.
>
> I did think of that, but it's too user-unfriendly IMO.
> Heck, it's even developer-unfriendly IMO.
I don't see how it's any worse than giving them a choice of 3-4 preset
values. Especially with the current defaults being given as the
if-in-doubt option :)
This is would also be a good reason to have a CONFIG_ADVANCED_OPTIONS
globally, ala what's in arch/ppc/Kconfig now. If selected, you can pick
some 'user-unfriendly' options, and otherwise a default is picked for
you.
This is also a good argument for the TWEAKS stuff I talked about a while
ago, but haven't found the time yet to finish the dependancy stuff (it
works ala CONFIG stuff now, _except_ for a new TWEAK key).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
next prev parent reply other threads:[~2003-01-06 19:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-02 23:09 [PATCH] configurable LOG_BUF_SIZE Randy.Dunlap
2003-01-06 18:50 ` Tom Rini
2003-01-06 18:57 ` Randy.Dunlap
2003-01-06 19:06 ` Tom Rini
2003-01-06 19:05 ` Randy.Dunlap
2003-01-06 19:15 ` Tom Rini [this message]
2003-01-06 19:16 ` Linus Torvalds
2003-01-06 19:20 ` Randy.Dunlap
2003-01-06 21:06 ` Randy.Dunlap
2003-01-06 21:26 ` Tomas Szepe
2003-01-06 22:04 ` Randy.Dunlap
2003-01-06 22:56 ` Tom Rini
2003-01-06 23:30 ` [PATCH] configurable LOG_BUF_SIZE (updated) Randy.Dunlap
2003-01-06 23:57 ` Andrew Morton
2003-01-06 23:57 ` Randy.Dunlap
2003-01-07 0:12 ` Randy.Dunlap
2003-01-07 0:44 ` [PATCH] configurable LOG_BUF_SIZE (update-2) Randy.Dunlap
2003-01-07 0:12 ` [PATCH] configurable LOG_BUF_SIZE Roman Zippel
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=20030106191531.GE796@opus.bloom.county \
--to=trini@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rddunlap@osdl.org \
--cc=torvalds@transmeta.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