From: Thomas Gleixner <tglx@linutronix.de>
To: Alex Dubov <oakad@yahoo.com>
Cc: linux-kernel@vger.kernel.org, joern@logfs.org, ben@fluff.org
Subject: Re: Smartmedia/xd card support - request for comments
Date: Fri, 18 Apr 2008 11:35:13 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.1.10.0804181126350.3261@apollo.tec.linutronix.de> (raw)
In-Reply-To: <143829.94600.qm@web36707.mail.mud.yahoo.com>
On Fri, 18 Apr 2008, Alex Dubov wrote:
>
> First, with all the respect to Jorn, alauda driver can only be
> considered "proof of concept". It does not try to abstract any
> smartmedia functionality.
>
> Second, ssfdc is hopelessly obsolete and requires rewrite.
Nobody claimed that it is perfect.
> Third, there's no attempt made by mtd to support advanced
> functionality present in many smartmedia and all memorystick
> readers: adapter side copy and multi page programming (this mostly
> relates to memorystick, of course). I also failed to see any support
> for device writing policy, needed to discern, for example,
> sequential page programmable devices vs. block programmable
> devices. I also failed to see an unified approach to page-accessible
> devices, meaning duplication of "bouncing" code in the backends.
And instead of addressing the missing features and shortcomings you
add a new duplicated code layer which is only useful for a restricted
set of hardware.
> Considering all this, amount of effort needed for satisfactory
> support of smartmedia through mtd was found by me to be far greater
> than coming with stand-alone implementation.
Yeah and you made this decision on your own w/o even discussing the
issues at hand with the mtd developers before implementing a separate
code stack. And now we should be impressed and merge it. That's not
the way it works.
> I do agree, that eventually my work can be merged into mtd. I don't
> see what prevents merging of my implementation as is on an interim
> basis, considering there are no real alternatives.
Merging your code as is is a bad idea as it contains userspace visible
changes which can not be undone easily. Interim solutions burden more
problems on us than they solve.
Thanks,
tglx
next prev parent reply other threads:[~2008-04-18 9:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-17 8:50 Alex Dubov
2008-04-17 9:01 ` Ben Dooks
2008-04-17 9:11 ` Alex Dubov
2008-04-17 13:10 ` Andy Lutomirski
2008-04-17 13:36 ` Arnd Bergmann
2008-04-17 13:38 ` Thomas Gleixner
2008-04-17 14:07 ` Jörn Engel
2008-04-17 19:11 ` Thomas Gleixner
2008-04-17 21:21 ` Jörn Engel
2008-04-18 8:47 ` Alex Dubov
2008-04-18 9:35 ` Thomas Gleixner [this message]
2008-04-19 2:49 ` Alex Dubov
2008-04-19 5:56 ` Thomas Gleixner
2008-04-18 14:00 ` Jörn Engel
2008-04-19 3:05 ` Alex Dubov
2008-04-19 6:37 ` Thomas Gleixner
2008-04-19 16:35 ` Jörn Engel
2008-04-20 2:25 ` Alex Dubov
2008-04-17 13:35 ` Thomas Gleixner
2008-04-17 14:19 ` Jörn Engel
2008-04-19 8:31 matthieu castet
2008-04-20 16:01 ` Jörn Engel
2008-04-21 1:33 ` Alex Dubov
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=alpine.LFD.1.10.0804181126350.3261@apollo.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=ben@fluff.org \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.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
Powered by JetHome