linux-kernel - Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

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: <20070321130320.GC495@lazybastard.org>
Date:	Wed, 21 Mar 2007 14:03:21 +0100
From:	Jörn Engel <joern@...ybastard.org>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	David Lang <david.lang@...italinsight.com>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	Theodore Tso <tytso@....edu>,
	Artem Bityutskiy <dedekind@...radead.org>,
	Matt Mackall <mpm@...enic.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Frank Haverkamp <haver@...t.ibm.com>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

*sigh*

I really did not want to become involved in this.  So please be nice and
leave the flamethrower in your weapon closet or I will disappear again
before you can say "fire".

On Tue, 20 March 2007 21:32:40 +0000, David Woodhouse wrote:
> On Tue, 2007-03-20 at 10:58 -0800, David Lang wrote:
> > What Matt and Ted are looking at is the question 'are flash devices close enough 
> > to other block devices that it would make sense to change the existing linux 
> > definition of a block device to handle the special requirements of flash'
> 
> I've seen no real proposals about how this could be done, so it's a
> purely academic question.

What you have seen and shot down were patches to make mtd more generic.
So let me just assume both mtd and jffs2 were generic, even though they
currently aren't.

In very broad terms, an mtd is a device with:
1. a read operation
2. a write operation
3. an erase operation
4. a minimal write blocksize
5. a minimal erase blocksize
6. a method to query bad eraseblocks
7. a method to mark bad eraseblocks

Anything else?  There are many more fields, but I believe this is the
essential.  point() and unpoint() were omitted, because they are just
one option to provide XIP.  filemap_xip.c is another used for block
devices.

In very broad terms, a block device has:
1. a read operation
2. a write operation
3. some devices have an ioctl() for erase, but that is uncommon
4. a blocksize

What is missing?  Obviously the erase operation needs to become a
first-class citizen and block devices need two fields for the two
meaningful blocksizes.  And they need methods to query and set bad
blocks.

So far it looks simple enough.  Obviously there are many messy details
left out, so it will be a lot of work in practice.  So the question is:
is it worth it?

What are the gains from combining mtd and block devices?

[ And at this point I would like to state again that I don't want to
become involved in the UBI discussion.  The question whether two
seperate subsystems make sense is quite independent and I don't want
both discussions to get mixed up. ]

Jörn

-- 
He who knows others is wise.
He who knows himself is enlightened.
-- Lao Tsu
-
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/