linux-kernel - Re: [PATCH 41/44 take 2] [UBI] gluebi unit header

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: <1171891825.13817.53.camel@sauron>
Date:	Mon, 19 Feb 2007 15:30:25 +0200
From:	Artem Bityutskiy <dedekind@...radead.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Frank Haverkamp <haver@...t.ibm.com>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 41/44 take 2] [UBI] gluebi unit header

On Sat, 2007-02-17 at 22:14 +0100, Arnd Bergmann wrote:
> This approach doesn't seem to make sense at all. If the MTD device interface
> is flawed, the right approach should be to fix that instead. After all,
> there are not many users of the MTD interface, so you should be able to
> adapt them.

MTD interface is not flawed, why? It is a good abstraction for flash
chips. 

UBI provide too many new services to utilize MTD interface. UBI != MTD,
but UBI may behave like MTD, although it is wider.

> In fact, I would expect that there is much more reason to merge the existing
> MTD interface with the block interface in the kernel

I do not think so, but the idea sounds exciting, please, talk to dwmw2
about this. But surely you know how different flash devices and HDD's
are: http://www.linux-mtd.infradead.org/faq/general.html

MTD devices are bare flashes.
Block devices are HDDs, MMCs, SDs, USB sticks, etc.

> but you now introduce
> a third interface that is unrelated to the first two

Why not? UBI is something which works on top of MTD, so it does relate
to MTD. But yes, it has nothing to do with block devices, I do not why
you talk about them. They are just irrelevant in my opinion, lets remove
them from discussion.

> , and make another
> conversion to convert it back?

All the the conversion things were created as debugging tools. I have
not heard anybody used them in production. But may be someone do, but
this is rare though and they must have _really good reasons_ for this.

> Let's assume I want to use the wear levelling capabilities of UBI on top
> of an SD card, and use the ext3 file system on top of it.

I do not see any point in this. SD card is a block device. It was
designed to be a block device. Using it for different purpose does not
look reasonable. Use bare flashes instead.

But technically it is possible to add block device back-end support to
UBI, but I do not know any real use-case for this.

>  I get a stack of
> 
> 1. MMC
Block device.
> 2. block2mtd
A debugging tool to develop flash software on host. Not normally used
for other purposes.
> 3. UBI
Close to MTD but also have a lot of new services.
> 4. gluebi
MTD devices emulated by UBI.
> 5. mtdblock
Stupid FTL driver, to emulated block devices on top of MTD. Too
straightforward, may only be used in RO mode. Any use in RW mode is
dangerous as you loose whole eraseblock in case of an unclean reboot.
> 6. VFS
Generalized FS view of the kernel.

> when in an ideal world, it should just be
> 
> 1. MMC
Just all block devices.
> 2. UBI
Is MTD here?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

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