linux-kernel - Re: [PATCH 0/2][MTD] Support for

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]

Message-ID: <ac9c93b10808220135v26141113ud799bc56a744c64e@mail.gmail.com>
Date:	Fri, 22 Aug 2008 10:35:19 +0200
From:	"Frans Meulenbroeks" <fransmeulenbroeks@...il.com>
To:	"Bruce Leonard" <brucle@...thlink.net>
Cc:	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: [PATCH 0/2][MTD] Support for > 2GiB MTD devices

Suggest you also post this to linux-mtd@...ts.infradead.org

2008/8/22 Bruce Leonard <brucle@...thlink.net>:
> All,
>
> Over the course of the last several months, I've been working on adding support to
> the kernel for MTD devices that exceed 2GiB in size.  In my particular case I
> have a need for 8GiB of NAND flash that appears as a single device.  I'm now
> ready to submit my (first ever!) patch (please be kind :)  ).
>
> Design Details:
> The problem - The size field of struct mtd_info is only 32-bits, which limits
>        the size of mtd devices to 2GiB (0x80000000).
> The solution - The size of a device can be calculated buy multiplying the number
>        of erase blocks by the erase block size.  I added a new field to struct
>        mtd_info to hold the number of erase blocks and an inline function to
>        determine the device size by returning mtd_info->size if it's non-zero
>        or returning (mtd_info->num_eraseblocks * mtd_info->erasesize).
>
> A couple of comments.  First and foremost, these patches don't completely change
> the MTD layer.  Due to my in-experience outside of what I was focused on
> (NAND/UBI/UBIFS/MTDCHAR) I felt it was best if I restricted my changes to what I
> knew.  If the community feels I need to take these changes into the rest of the
> MTD layer please advise.  Secondly, there were changes that I needed to make in
> mtd-utils, but I again only focused on the UBI sub-set.  mtd-utils no longer builds
> because of the changes (though the UBI tools still build).  But I really do NOT
> feel qualified to make changes to the rest of mtd-utils as they're tools I don't
> use and don't understand and I don't want to accidentaly break something I don't
> understand.  The changes in mtd-utils are the same changes as in
> .../include/linux/mtd/mtd.h and .../include/mtd/mtd-abi.h.  If anyone has a
> suggestion as to how I should handle mtd-utils I would appreciate it.
>
> Thanks again to everyone who's answered my endless stupid questions.
>
> Bruce
>
> --
> 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/
>
--
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/