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] [day] [month] [year] [list]

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

> 
> That's all fine. Nobody asked for the backend to know about smartmedia
> on FLASH format details. The MTD NAND FLASH layer does not care about
> on FLASH data format at all. It provides merily access on the hardware
> level.
> 
> I agree that your approach of making the SM/XD layer capable of
> handling clever and dumb hardware adapters is a good one.
> 
> The point where I stringly disagree is that your implementation is
> forcing people with dumb hardware (see drivers/mtd/nand/*) to
> reimplement the (maybe already) existing drivers in order to make use
> of the ssfdc format, which will not work with the following real world
> example:
> 
> ------------------
> | NAND controller |----------| On board NAND
> | with HW ECC     |
> |                 |----------| SmartMedia Card
> ------------------
> 
> Having a separate driver infrastructure for clever controllers, which
> provide only semi raw access to the FLASH chip is fine simply because
> such controllers do not fit into the MTD layer.

Shouldn't both smartmedia and legacy memorystick controllers can be considered
"semi-raw"? In second case, media itself implements "semi-raw" flash interface.

> 
> > I meant here the ability of user to look and modify CIS page, as
> > well as look at the current block translation table.
> 
> Well, you probably do this with an iotctl anyway. So what's preventing
> you to modify the mtd block layer to handle client private ioctls.

I think ioctls are nowhere as convenient as sysfs file. I believe many people
share this point of view - after all, ioctls throw a lot of different
functionality into one basket, using cryptic codes.

> 
> Also there is no real requirement to use the mtd block layer at all
> for that. Putting your layer on top of the raw MTD device is fine IMO.

I see that raw mtd operates on buffer pointers, rather than scatterlists. From
my understanding, it demands "map" and possibly "bounce" operation elsewhere,
incurring sizable overhead on performance (for fast media, the waits in the
blocking read/write operations will also have considerable effect). Are there
any plans to address this issue?

> >
> > Revamping the underlying architecture of mtd will break a lot of
> > stuff in the process, doesn't it?
> 
> That's the best excuse I ever heard for not improving code which has
> shortcomings.
> 

Can't agree. It's one of the most commonly used, according to my experience.



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