All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.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: Wed, 21 May 2008 09:47:12 +0300	[thread overview]
Message-ID: <1211352433.31023.19.camel@sauron> (raw)
In-Reply-To: <411628.55054.qm@web36703.mail.mud.yahoo.com>

Hi,

I do not know much about SmartMedia and so on, so I cannot really
comment. I mail more because I am afraid your mail will not be answered.
Probably you should keep CCing LKML, not sure.

On Tue, 2008-05-20 at 06:59 -0700, Alex Dubov wrote:
> And third, architectural switch I'm proposing should not require modification
> to low level chip drivers or higher level functionality of UBI kind. They can
> be glued together with relative ease (callback architecture is quite flexible).
> My target is device management and FTL drivers.
> 
> Therefore, I propose (and intend to implement) a new architecture for MTD core,
> modeled after the block device API. The "alpha" version of it is here:
> 
> http://gentoo-wiki.com/User:Oakad/mtd_proposal

I've briefly read through this. I think it is nice having an
asynchronous interface based on requests. Probably UBI/UBIFS would
benefit from it as well. Just few thoughts:

1. You will probably need to solve the horrible MTD problem - it does
not support devices larger than 4GiB because it uses absolute 32-bit
offsets.
2. You will need to make MTD sysfs-aware.
3. Removable devices support is a separate task as well.
4. IMO you should preserve the low-level flash access interface and the
request-based infrastructure should yous it as the back-end. Is this
possible? Or my understanding of smartmedia is incorrect? I thought it
is accessible as bare NAND and you have to support its FTL in software. 

Probably there are other tasks. I think you should work on these smaller
tasks separately and make them go in one by one, instead of trying to
put all together.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2008-05-21  6:47 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 [this message]
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
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=1211352433.31023.19.camel@sauron \
    --to=dedekind@infradead.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 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.