From: Willy Tarreau <willy@w.ods.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: log-buf-len dynamic
Date: Tue, 23 Sep 2003 21:02:19 +0200 [thread overview]
Message-ID: <20030923190219.GA5997@alpha.home.local> (raw)
In-Reply-To: <20030923162319.GA1269@velociraptor.random>
[Cc: list stripped down]
On Tue, Sep 23, 2003 at 06:23:19PM +0200, Andrea Arcangeli wrote:
> You simply want *two* different APIs, where one is worhtless and
> obsoleted by the more powerful one.
I never said I wanted *two* of them. I proposed first a fairly non-intrusive
one which doesn't add any line of code, just defines, and managed to reunify
architectures which used different values by default.
*You* proposed a second one. I have no objections against it, as I said, since
I certainly understand that some people would prefer to use it. But *you*
decided that mine was totally unusable and obsoleted by yours, reason for it to
be removed. And this is *that* I objected to. Since the can both coexist and
fit different people's needs without adding a byte of code (at least for mine),
I don't see the goal in eliminating it, deciding unilaterally that nobody will
use it.
I repeat, at the end, I don't mind. I have the patch and can live with one
more patch, as I did before. It's just the fact that you decide for everyone
that always adding a command line option is more convenient than a once-for-all
fixed config option.
> My API is good for everyone, yours is not
I'm impressed that you know so many people. I know that mine at least
satisfies a few collegues, customers, and I. So I deduced that it might be
useful to others too. Even Marcelo thought the same a time ago.
> I don't see why we've to keep both when nobody depends on yours yet.
Nobody depends on mine, since it doesn't change defaults nor semantics. Perhaps
some people depend on yours *not* being in. You changed LOG_BUF_LEN from a
define to a static, and THAT could break other external patches. BTW, I've
just checked 2.4.22aa1, I noticed that you removed kmsgdump, is it because it
doesn't apply, compile or work anymore since your API change ?
Honnestly, I simply took a conservative approach. My proposal not being what
will save the world, I'm 100% with you on that. Mine being useless to everyone,
I'm only 20% with you on that. Yours being "good for everyone", I'm only 20%
with you on that too, and perhaps less since it might break some compatibility.
Yours *is* interesting to some aspects, but is not an equivalent.
> I just don't buy the fact that you don't like to pass params to the
> kernel because you already do, you have to or it won't boot on a system
> different than the one that you compiled the kernel.
Believe it or not, there are people who don't like to pass params to the
kernel. I just told a friend while I was typing this mail, and he replied me
"he must be joking !". So at least, we're two on earth.
> Yeah, I'm forcing you to waste a dozen bytes of disk space in
> /etc/lilo.conf, you can definitely claim that, but I don't that as an
> argument either (delete the spaces/tabs and you may save more). And
> maybe thanks to this you won't run into the number of kernel images
> limitation anymore.
OK Andrea, you're in a bad mood today. You're trying to prove me crazy. I
won't fight. You're the kernel hacker. Not me. I have never been proud of
putting a patch in the kernel and never will be. I'm more ashamed when I send
an obvious "fix" which breaks someone's setup. Your attitude today seems to be
the opposite. Your patch is useful, I won't contest that. It won't annoy anyone,
I'll let others report it to you themselves, I've done my part of it. But they
will waste their time since you don't want to listen and will try to sell your
patch anyway because "it's good for everyone" as you stated it.
> I'm deinitely against worthless APIs in the kernel, when more powerful
> one exists, and they give you zero disavantage
There are people out there who are against worthless lines in config files,
and against APIs which break other patches.
> As for decreasing the buf size, my option will allow you to decrease it
> too after I fix it! While the shift only let you increase the buf size,
> not decrease. So you should prefer the dynamic API too.
I don't see why you say that ! Set LOG_BUF_SHIFT to 10 and you'll have 1kB !
Have a good night anyway,
Willy
next prev parent reply other threads:[~2003-09-23 19:03 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-22 19:48 log-buf-len dynamic Andrea Arcangeli
2003-09-23 1:51 ` Matthew Wilcox
2003-09-23 21:08 ` Andrea Arcangeli
2003-09-23 4:28 ` Willy Tarreau
2003-09-23 12:49 ` Andrea Arcangeli
2003-09-23 14:06 ` Willy Tarreau
2003-09-23 14:44 ` Andrea Arcangeli
2003-09-23 15:01 ` Jan Evert van Grootheest
2003-09-23 15:41 ` Andrea Arcangeli
2003-09-23 16:09 ` Willy Tarreau
2003-09-23 16:26 ` Andrea Arcangeli
2003-09-23 16:56 ` Ruth Ivimey-Cook
2003-09-23 17:40 ` Tom Zanussi
2003-09-23 17:53 ` Andrea Arcangeli
2003-09-23 21:37 ` Andrew Morton
2003-09-23 22:22 ` Andrea Arcangeli
2003-09-24 0:15 ` Andrew Morton
2003-09-24 0:38 ` Andrea Arcangeli
2003-09-23 16:06 ` Willy Tarreau
2003-09-23 16:23 ` Andrea Arcangeli
2003-09-23 19:02 ` Willy Tarreau [this message]
2003-09-23 22:34 ` Andrea Arcangeli
2003-09-23 23:29 ` Willy Tarreau
2003-09-23 23:48 ` Andrea Arcangeli
2003-09-23 23:50 ` Willy Tarreau
2003-09-23 12:46 ` Daniel Jacobowitz
2003-09-25 13:40 ` marcelo
2003-09-26 20:26 ` Andrea Arcangeli
[not found] <20030923142706.54b2428a.davem@redhat.com>
2003-09-23 21:53 ` Linus Torvalds
2003-09-23 22:15 ` Andrea Arcangeli
2003-09-23 22:54 ` Linus Torvalds
2003-09-24 0:36 ` Andrea Arcangeli
2003-09-24 1:19 ` Larry McVoy
2003-09-24 2:04 ` andrea
2003-09-24 2:29 ` Larry McVoy
2003-09-24 2:39 ` Andrea Arcangeli
2003-09-24 3:16 ` Larry McVoy
2003-09-24 3:31 ` Rik van Riel
2003-09-24 3:45 ` Larry McVoy
2003-09-24 3:54 ` Linus Torvalds
2003-09-24 4:12 ` Rik van Riel
2003-09-24 21:11 ` yodaiken
2003-09-24 13:09 ` Alan Cox
2003-09-24 18:56 ` Jörn Engel
2003-09-24 3:46 ` Andrea Arcangeli
2003-09-24 4:02 ` Larry McVoy
2003-09-24 4:06 ` Rik van Riel
2003-09-24 2:36 ` Linus Torvalds
2003-09-24 2:48 ` Andrea Arcangeli
2003-09-24 3:06 ` Linus Torvalds
2003-09-24 3:28 ` Andrea Arcangeli
2003-09-24 3:38 ` Linus Torvalds
2003-09-24 3:56 ` Andrea Arcangeli
2003-09-24 4:26 ` viro
2003-09-24 3:42 ` Rik van Riel
2003-09-24 3:11 ` David S. Miller
2003-09-24 14:43 ` Roman Zippel
2003-09-25 4:08 ` Miles Bader
2003-09-25 4:20 ` Nick Piggin
2003-09-25 17:15 ` Eric W. Biederman
2003-09-25 17:30 ` Linus Torvalds
2003-09-25 17:57 ` Jeff Garzik
2003-09-25 18:22 ` Jörn Engel
2003-09-25 18:33 ` Randy.Dunlap
2003-09-25 18:36 ` Larry McVoy
2003-09-25 19:02 ` Jörn Engel
2003-09-25 18:28 ` Charles Cazabon
2003-09-25 18:29 ` Larry McVoy
2003-09-25 20:15 ` David Lang
2003-09-25 20:27 ` Larry McVoy
2003-09-29 8:56 ` Rob Landley
2003-09-29 11:24 ` John Bradford
2003-09-29 12:30 ` Rob Landley
2003-09-29 15:22 ` John Bradford
2003-09-29 13:20 ` Rik van Riel
2003-09-29 13:23 ` Valdis.Kletnieks
2003-09-29 15:03 ` Larry McVoy
2003-09-29 18:21 ` Hua Zhong
2003-09-29 15:07 ` Larry McVoy
2003-09-25 19:23 ` Eric W. Biederman
2003-09-25 17:31 ` Christoph Hellwig
2003-09-25 19:28 ` Erik Andersen
2003-09-25 17:36 ` Dave Jones
2003-09-25 18:34 ` Larry McVoy
2003-09-25 18:35 ` Eric W. Biederman
2003-09-25 18:49 ` Larry McVoy
2003-09-25 20:02 ` Eric W. Biederman
2003-09-25 23:36 ` Pau Aliagas
2003-09-26 2:25 ` Miles Bader
2003-09-26 4:38 ` Davide Libenzi
2003-09-26 17:09 ` John Goerzen
2003-09-24 7:56 ` Pau Aliagas
-- strict thread matches above, loose matches on Subject: below --
2003-09-24 17:39 Ken Ryan
2003-09-25 19:43 Mudama, Eric
2003-09-26 13:24 Samium Gromoff
2003-09-26 14:49 ` viro
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=20030923190219.GA5997@alpha.home.local \
--to=willy@w.ods.org \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.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