From: "Hua Zhong" <hzhong@gmail.com>
To: "'Ray Lee'" <ray-lk@madrabbit.org>
Cc: "'Theodore Tso'" <tytso@mit.edu>,
"'Linus Torvalds'" <torvalds@linux-foundation.org>,
"'Jens Axboe'" <jens.axboe@oracle.com>,
"'Linux Kernel Mailing List'" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 0/8][RFC] IO latency/throughput fixes
Date: Mon, 6 Apr 2009 15:25:36 -0700 [thread overview]
Message-ID: <003401c9b706$9c4c1b50$d4e451f0$@com> (raw)
In-Reply-To: <2c0942db0904061504l6504934bi446f7425fcd38470@mail.gmail.com>
> Speaking as another embedded Linux guy, I don't update kernels on my
> embedded platforms willy-nilly, nor do I design a library that relies
> upon some default behavior without specifying it explicitly. That's
> just one of the prices of doing embedded development.
>
> Your argument seems to be that someone may be relying upon default
> kernel behavior and, at the same time, is willing to continually
> upgrade their kernel. I'd argue that person is, y'know, nuts. If
> they're willing to upgrade their kernel on something that has that
> stringent of requirements, then they should be willing to force a
> mount option at the same time.
You are implying that if someone upgrades their kernel, then he must
1) upgrade it continuously and 2) without any scrutiny. Both are untrue.
There are certain things people expect from the kernel, such as
no ABI changes. To me ext3 default option falls into this category.
And even if they are nuts, you can't prove they don't exist, especially
given how many software already depends on the ordered mode.
You also conveniently forgot to quote my question about security. Both
are valid questions, not something I just totally made up.
> If they're willing to upgrade their kernel blindly, then they
> shouldn't be doing embedded development.
Linus once said that if you don't understand "not breaking user space" then
you should not be doing kernel development. Or something to that extent.
next prev parent reply other threads:[~2009-04-06 22:26 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-06 12:48 [PATCH 0/8][RFC] IO latency/throughput fixes Jens Axboe
2009-04-06 12:48 ` [PATCH 1/8] block: change the request allocation/congestion logic to be sync/async based Jens Axboe
2009-04-06 12:48 ` [PATCH 2/8] Add WRITE_SYNC_PLUG and SWRITE_SYNC_PLUG Jens Axboe
2009-04-06 12:48 ` [PATCH 3/8] block: fsync_buffers_list() should use SWRITE_SYNC_PLUG Jens Axboe
2009-04-06 12:48 ` [PATCH 4/8] jbd: use WRITE_SYNC_PLUG instead of WRITE_SYNC Jens Axboe
2009-04-06 12:48 ` [PATCH 5/8] jbd2: " Jens Axboe
2009-04-06 12:48 ` [PATCH 6/8] block: enabling plugging on SSD devices that don't do queuing Jens Axboe
2009-04-06 12:48 ` [PATCH 7/8] block: Add flag for telling the IO schedulers NOT to anticipate more IO Jens Axboe
2009-04-06 12:48 ` [PATCH 8/8] block: switch sync_dirty_buffer() over to WRITE_SYNC Jens Axboe
2009-04-06 13:04 ` [PATCH 0/8][RFC] IO latency/throughput fixes Jens Axboe
2009-04-06 13:13 ` Jens Axboe
2009-04-06 15:37 ` Linus Torvalds
2009-04-06 16:57 ` Jens Axboe
2009-04-07 3:28 ` Chris Mason
2009-04-06 15:04 ` Linus Torvalds
2009-04-06 15:10 ` Jens Axboe
2009-04-06 15:45 ` Linus Torvalds
2009-04-06 17:01 ` Jens Axboe
2009-04-06 18:31 ` Theodore Tso
2009-04-06 19:57 ` Linus Torvalds
2009-04-06 20:10 ` Linus Torvalds
2009-04-06 21:26 ` Theodore Tso
2009-04-06 20:12 ` Hua Zhong
2009-04-06 20:20 ` Linus Torvalds
2009-04-06 21:19 ` Theodore Tso
2009-04-06 21:35 ` Hua Zhong
2009-04-06 22:04 ` Ray Lee
2009-04-06 22:17 ` Linus Torvalds
2009-04-06 23:10 ` Linus Torvalds
2009-04-07 7:51 ` Geert Uytterhoeven
2009-04-07 10:36 ` Ingo Molnar
2009-04-07 14:10 ` Diego Calleja
2009-04-08 12:04 ` Ingo Molnar
2009-04-08 12:56 ` Denys Vlasenko
2009-04-08 13:27 ` Ingo Molnar
2009-04-07 13:35 ` Mark Lord
2009-04-07 14:33 ` Linus Torvalds
2009-04-07 19:24 ` Mark Lord
2009-04-07 19:45 ` Jeff Garzik
2009-04-07 20:53 ` Mike Galbraith
2009-04-09 2:40 ` Eric Sandeen
2009-04-09 14:01 ` Ric Wheeler
2009-04-06 22:25 ` Hua Zhong [this message]
2009-04-06 22:48 ` Ray Lee
2009-04-06 22:52 ` Hua Zhong
2009-04-06 23:19 ` Alan Cox
2009-04-07 3:52 ` Chris Mason
2009-04-07 4:13 ` Trenton D. Adams
2009-04-07 4:27 ` Linus Torvalds
2009-04-07 4:48 ` Trenton D. Adams
2009-04-07 5:02 ` Linus Torvalds
2009-04-07 5:23 ` Hua Zhong
2009-04-07 6:27 ` Trenton D. Adams
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='003401c9b706$9c4c1b50$d4e451f0$@com' \
--to=hzhong@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ray-lk@madrabbit.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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