All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: "Jörn Engel" <joern@logfs.org>
Cc: linux-mtd@lists.infradead.org, Bruce_Leonard@selinc.com
Subject: Re: mtd_info->size again (lengthy)
Date: Mon, 9 Jun 2008 14:21:17 +0100	[thread overview]
Message-ID: <20080609132117.GC29526@shareable.org> (raw)
In-Reply-To: <20080608121020.GA13200@logfs.org>

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.

Or, maybe we should change the name to flash everywhere.  Most people
recognise that nowadays - flash is a common term.

> Submit_fio has the advantage of allowing asynchronous operations,
> queueing, out-of-order completion and all those goodies.  If you
> have several chips in a device, I'm sure you want those as well.

Yes!  I always wondered why it wasn't done like that from the beginning.

> 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.  I strongly suggest supporting erasesizes
comparable with the device size.  That doesn't mean writesize has to
be that big - writesize should fit in size_t (actually ssize_t), just
like sys_write().

> > It still leaves the problem of converting all driver.  I've only started
> on mtdram - because it is simple and everyone can test it.  Other
> drivers can follow over time.  Users like jffs2 could be converted as
> well, but I'd rather leave them for now.

> We want synchronous wrappers around submit_fio anyway, as those are
> useful for development and for trivial performance-agnostic code.
> Comments?

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.

-- Jamie

  parent reply	other threads:[~2008-06-09 13:21 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 [this message]
2008-06-09 14:36     ` Jörn Engel
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=20080609132117.GC29526@shareable.org \
    --to=jamie@shareable.org \
    --cc=Bruce_Leonard@selinc.com \
    --cc=joern@logfs.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 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.