public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Alex Dubov <oakad@yahoo.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Support of removable MTD devices and other advanced features (follow-up from lkml)
Date: Fri, 23 May 2008 15:28:53 +0200	[thread overview]
Message-ID: <20080523132853.GC22384@logfs.org> (raw)
In-Reply-To: <115582.37719.qm@web36706.mail.mud.yahoo.com>

On Fri, 23 May 2008 05:49:48 -0700, Alex Dubov wrote:
> 
> We are talking about somewhat different things here. Userspace visible devices
> (highest layer in mtd stack) must support something complex. Lower levers in
> the mtd stack - not necessarily so.
> 
> Highest level "raw mtd" devices can be normal block devices with support for
> custom commands. Intermediate and low level modules can do with simple
> interface.

Either I misunderstand you or you are forgetting that filesystems deal
with raw mtd devices, which are the lowest levels in your stack afaics.
JFFS2 and LogFS will deal directly with the chip driver and bypass any
intermediate layers.  UBIFS will talk to UBI as a middle layer, which
again talks directly to the chip driver.

> Then, there should be a layer akin to "md" that will allow creation of flash
> raids. After all, we are not limited in number of intermediate devices present
> in the kernel. We don't have to create userspace visible nodes for them.

True.  For me pure concatenation would be enough.  All I need is some
extra geometry information so I can decide which block belongs to which
chip.  In the simplest case something like "13 chips of 123MiB each,
linearly concatenated".  Different chips sizes are fine, different
erasesize and writesize may still work within reason.

So mtdconcat.c plus extended geometry information would be good enough.

Jörn

-- 
All art is but imitation of nature.
-- Lucius Annaeus Seneca

  reply	other threads:[~2008-05-23 13:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20 13:59 Support of removable MTD devices and other advanced features (follow-up from lkml) Alex Dubov
2008-05-21  6:47 ` Artem Bityutskiy
2008-05-21  8:41 ` Jörn Engel
2008-05-22  1:30   ` Alex Dubov
2008-05-22 15:10     ` Jörn Engel
2008-05-23  2:47       ` Alex Dubov
2008-05-23  5:50         ` Jörn Engel
2008-05-23  9:33           ` Alex Dubov
2008-05-23  9:59             ` Jörn Engel
2008-05-23 12:49               ` Alex Dubov
2008-05-23 13:28                 ` Jörn Engel [this message]
2008-05-24 13:12                   ` Alex Dubov
2008-05-24 17:56                     ` Jörn Engel
2008-05-25  3:41                       ` Alex Dubov
2008-05-25  7:25                         ` Jörn Engel
2008-05-25 13:30                           ` Jamie Lokier
2008-05-25 16:24                             ` Jörn Engel
2008-05-25 16:35                               ` Jamie Lokier
2008-05-25 16:55                                 ` Jörn Engel
2008-05-26  2:12                           ` Alex Dubov
2008-05-21  9:06 ` David Woodhouse
2008-05-21  9:29   ` Jörn Engel
2008-05-21 15:20     ` Alex Dubov
2008-05-21 15:22       ` David Woodhouse
2008-05-21 15:41         ` Alex Dubov
2008-05-21 20:45           ` 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=20080523132853.GC22384@logfs.org \
    --to=joern@logfs.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=oakad@yahoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox