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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.