linux-kernel - Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

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: <a95a62fe0903312149j482c1684k564896e1981f9819@mail.gmail.com>
Date:	Tue, 31 Mar 2009 21:49:03 -0700
From:	Kevin Cernekee <kpc.mtd@...il.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Linux MTD <linux-mtd@...ts.infradead.org>,
	Kay Sievers <kay.sievers@...y.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

On 3/31/09, David Brownell <david-b@...bell.net> wrote:
>> 2) region_info_user fields?  Not really sure how this would work.
>> Maybe a separate subdirectory for each region?
>
> I'm not sure I've ever had reason to care about a "region" (whatever
> that is!) with MTD hardware.

Erase Block Regions.  From the CFI spec:

"x specifies the number of regions within the device containing one or
more contiguous Erase Blocks of the same size.  For example, a 128KB
device (1Mb) having blocking of 16KB, 8KB, four 2KB, two 16KB, and one
64KB is considered to have 5 Erase Block Regions."

This is fairly common on parallel NOR devices.  Probably less so on
huge NAND devices.

> I suspect that a lot of interesting questions could come up in
> the context of enhancing mtd-utils to work with sysfs and bigger
> NAND chips.  Some might relate to "regions".

Right, this sysfs requirement raises a number of issues that need to
be fully thought out in order to make sure the new interface is a
suitable replacement for the "INFO" ioctls.  For instance:

1) If each region is a subdirectory, are user programs supposed to use
readdir() to count them?  Is ioctl(MEMGETREGIONCOUNT) still the
preferred method?  Or do we make a new "regioncount" sysfs attribute?

(A somewhat related question is whether MEMGETREGIONCOUNT only exists
because it was impossible to expand the MEMGETINFO struct.  After all,
it's just copying another field from the mtd_info struct.)

2) How are user programs expected to access MTD sysfs?  Do we
introduce a new libsysfs dependency, or roll our own implementation?
Are there any past examples of ioctls being phased out in favor of
sysfs, particularly in subsystems that are popular on embedded
platforms?

3) What should the mtd-utils changes look like?  Do we define
backward-compatibility wrapper functions that try to work the same way
the ioctls used to?  New libraries and layers of abstraction?  Or
something in the middle?
--
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/