From: "Jörn Engel" <joern@logfs.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: linux-mtd@lists.infradead.org, Bruce_Leonard@selinc.com
Subject: Re: mtd_info->size again (lengthy)
Date: Mon, 9 Jun 2008 16:36:33 +0200 [thread overview]
Message-ID: <20080609143633.GA22447@logfs.org> (raw)
In-Reply-To: <20080609132117.GC29526@shareable.org>
On Mon, 9 June 2008 14:21:17 +0100, Jamie Lokier wrote:
> Jörn Engel wrote:
> > replacing them with submit_fio (or some equivalent function, if
> > people dislike the name).
>
> May I suggest submit_mtdio? One concept to one name, you know.
>
> F means flash, sure. But we don't call the devices /dev/flash0, /dev/flash1.
> Nor do we call it the Flash subsystem.
I never liked the name "mtd". It is unpronouncable and reeks of the
kind of premature overgeneralization big corporations usually come up
with. "One day this will cover all memory, including hard disks, cpu
caches and those five bytes in the rtc." Or some such madness.
But mtdio is even worse. Dude, what are you smoking? ;)
> Or, maybe we should change the name to flash everywhere. Most people
> recognise that nowadays - flash is a common term.
The old name - as stupid as it is - has become part of the eternal
interfaces. You'll never hunt it to extinction.
> > And while at it, replace the 32bit size with a 64bit blockno and 32bit
> > offset. Unless someone is stupid enough to create devices with 4G
> > erasesize, that should last for a human lifetime or something close.
>
> Although a single chip is unlikely to have 4GiB erasesize for a while,
> a cluster of chips might, and it should be possible to represent them
> as a single device.
When you have a cluster of chips, striping them and increasing writesize
and erasesize (and having each bad block kill perfectly good blocks in
the other stripes) may be the first idea you have. But I hope it won't
be the last.
Part of the reason for asynchronous interfaces is to make parallel chips
work fast without striping them. Or rather, make them work even faster
than stripes.
> I'm thinking we want asynchronous wrappers around the synchronous
> methods too, using a dispatch thread. So that drivers can be
> converted one by one, and old drivers don't need to be. Something like
> generic_submit_fio.
Maybe. That depends on when and how the users will take advantage of
the new interface. I have plans for logfs, but don't intend to convert
jffs2, mtdchar, mtdblock or ubi. If others do, please send patches.
Jörn
--
Public Domain - Free as in Beer
General Public - Free as in Speech
BSD License - Free as in Enterprise
Shared Source - Free as in "Work will make you..."
next prev parent reply other threads:[~2008-06-09 14:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-08 5:38 mtd_info->size again (lengthy) Bruce_Leonard
2008-06-08 12:10 ` Jörn Engel
2008-06-08 12:13 ` Jörn Engel
2008-06-09 2:51 ` Bruce_Leonard
2008-06-09 5:21 ` Jörn Engel
2008-06-09 4:43 ` Bruce_Leonard
2008-06-09 5:28 ` Jörn Engel
2008-06-09 13:21 ` Jamie Lokier
2008-06-09 14:36 ` Jörn Engel [this message]
2008-06-09 16:31 ` Jamie Lokier
2008-06-09 17:22 ` Jörn Engel
2008-06-10 10:56 ` Jamie Lokier
2008-06-10 11:46 ` Jörn Engel
2008-06-11 0:09 ` Bruce_Leonard
2008-06-11 7:18 ` Jörn Engel
2008-06-11 7:46 ` Bruce_Leonard
2008-06-11 9:13 ` Jörn Engel
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=20080609143633.GA22447@logfs.org \
--to=joern@logfs.org \
--cc=Bruce_Leonard@selinc.com \
--cc=jamie@shareable.org \
--cc=linux-mtd@lists.infradead.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