linux-kernel - Re: [RFC PATCH 0/7] mtd: partitions: add of_match

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: <CAMuHMdV2feXKWkJzRkMUBiAUCxp4LwaRgg+aPYwm0sUnKzm0Rg@mail.gmail.com>
Date:	Fri, 11 Dec 2015 17:00:28 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Michal Suchanek <hramrach@...il.com>
Cc:	Brian Norris <computersforpeace@...il.com>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Arnd Bergmann <arnd@...db.de>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	devicetree-spec@...r.kernel.org, Simon Arlott <simon@...e.lp0.eu>,
	Linus Walleij <linus.walleij@...aro.org>,
	Rafał Miłecki <zajec5@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	David Hendricks <dhendrix@...omium.org>,
	Jonas Gorski <jogo@...nwrt.org>,
	Rob Herring <robh+dt@...nel.org>,
	MTD Maling List <linux-mtd@...ts.infradead.org>,
	Hauke Mehrtens <hauke@...ke-m.de>
Subject: Re: [RFC PATCH 0/7] mtd: partitions: add of_match_table support

Hi Michal,

On Fri, Dec 11, 2015 at 4:34 PM, Michal Suchanek <hramrach@...il.com> wrote:
> On 11 December 2015 at 09:44, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>> On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
>> <computersforpeace@...il.com> wrote:
>>> On Sat, Dec 05, 2015 at 11:15:54AM +0100, Geert Uytterhoeven wrote:
>>>> On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>>>> <computersforpeace@...il.com> wrote:
>>>> > There have been several discussions [1] about adding a device tree binding for
>>>> > associating flash devices with the partition parser(s) that are used on the
>>>> > flash. There are a few reasons:
>>>> >
>>>> >  (1) drivers shouldn't have to be encoding platform knowledge by listing what
>>>> >      parsers might be used on a given system (this is the currently all that's
>>>> >      supported)
>>>> >  (2) we can't just scan for all supported parsers (like the block system does), since
>>>> >      there is a wide diversity of "formats" (no standardization), and it is not
>>>> >      always safe or efficient to attempt to do so, particularly since many of
>>>> >      them allow their data structures to be placed anywhere on the flash, and
>>>> >      so require scanning the entire flash device to find them.
>>>>
>>>> I read the second reason, but would it be useful to (partially) merge
>>>> block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos
>>>> partitions
>>>> on an mtd device??
>>>
>>> I kinda agree with Michal: is there a good use case?
>>
>> I don't have an immediate use case.
>> Just looking at it from a high-level viewpoint.
>>
>>> Really, MTD partitioning is not a highly-scalable design. Particularly,
>>> it's not typically that well-suited to large (read: unreliable) NAND
>>> flash, where fixing partitions at the raw flash level mostly serves to
>>> restrict UBI's ability to wear-level across the device. For that sort of
>>> case, it's best if people are using UBI volumes on a (mostly?)
>>> unpartitioned MTD, instead of using MTD partitions as the main
>>> separation mechanism. Also, most partition designs (either MTD or block)
>>> aren't very robust against bitflips, read disturb, etc.
>>>
>>> IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
>>> and so I don't plan to do that sort of work myself. If you can provide
>>> some better argument for it, and some nice maintainable code to go with
>>> it, then of course it could be considered :)
>>
>> There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
>> working on have.
>>
>
> Yes, you can dump the content of a NOR flash to a file, attach a loop
> device to it, and if block devices had the ability to use flash
> partitioning access the different partitions.
>
> Maybe it would be more useful to use some kind of mtdloop, though.
> There might even be one already. I never needed it.

That's the inverse, which looks like a solid use case to me ;-)
E.g. for investigation or virtualization.

You can do this already in userspace with kpartx, though.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/