linux-kernel - Re: Smartmedia/xd card support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0804181126350.3261@apollo.tec.linutronix.de>
Date:	Fri, 18 Apr 2008 11:35:13 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Alex Dubov <oakad@...oo.com>
cc:	linux-kernel@...r.kernel.org, joern@...fs.org, ben@...ff.org
Subject: Re: Smartmedia/xd card support - request for comments

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/