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]

Date:	Fri, 18 Apr 2008 19:49:45 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	linux-kernel@...r.kernel.org
Cc:	tglx@...utronix.de, joern@...fs.org, ben@...ff.org
Subject: Re: Smartmedia/xd card support - request for comments

> > 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 not expect you, or anybody, to be "impressed" with anything. As I said before, from my
analysis of mtd it will require a great deal of patching to acquire certain functionality. This
will invariably require a large time span, as many people depend on the mtd in it present state.

If your position on the proposed interim solution is definite "no", I'll make an effort to rewrite
the driver in the mtd-friendly way.

This brings me to the first technical question:

mtd_blkdevs breaks the block layer request into separate pages, effectively disabling lower layer
from making decision based on a real data block size, and using dma to any useful extent. What is
the proposed way to deal with this?

(By the way, first question already puts us into a "quirk" area of the statement "smartmedia are
flash chips with quirks". Both memorystick and smartmedia are always operated in tandem with their
controllers, as you could notice.)

      ____________________________________________________________________________________
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/