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: <143829.94600.qm@web36707.mail.mud.yahoo.com>
Date:	Fri, 18 Apr 2008 01:47:12 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	linux-kernel@...r.kernel.org
Cc:	joern@...fs.org, tglx@...utronix.de, ben@...ff.org
Subject: Re: Smartmedia/xd card support - request for comments

Unfortunately, I must say, Smartmedia is not supported on linux for any reasonable definition of
the word.

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.

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.

In general, block device emulation layer of mtd is incomplete at best.

No infrastructure exists for exporting and manipulation of metadata in userspace.

And, in general, architecture of mtd is suboptimal, relying on blocking calls (as opposed to
callback based architecture).

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. 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.

In case somebody is actually interested in looking at the code:

http://svn.berlios.de/wsvn/tifmxx/trunk/driver/#_trunk_driver_

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--
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/