Re: [Yaffs] bit error rates --> a vendor speaks

["Artem B. Bityutskiy" <dedekind@yandex.ru>]

Josh, I believe you're only *partially* right

Please, switch to "architecture mode", leave this "low-level programmer" 
mode. Forget about few bytes of DRAM for now, please! :-)

The bellow are different points which should help me to change your mind.

1. The region is an attribute of *flash chip*. The region is *not* an 
attribute of MTD device. MTD device may describe the whole flash chip, 
it may describe a part of flash chip (partitions), and it may describe 
many flash chips (concatenation).

So, I state: the notion of region has nothing to do with the notion of 
MTD device.

If you have a specific application, which works with a *flash chip* not 
an *MTD device*, please, introduce another software object, sort of 
"struct flash_chip". Let your applications to work with these "struct 
flash_chip" objects.

Putting references to regions to the MTD device structure (struct 
mtd_info) is *bad*.

2. Well, you're in ecstasy of the current approach (kidding :-) ). Then 
explain me, why if, let's say JFFS3, opens an MTD device, it has access 
to some weird "regions"? What's on earth is going on? This is definitely 
error-prone. This is messy. This is bad design. JFFS3 does not want to 
see regions.

3. Regions... How do you look at them?

We could look at them like this:
a). They are different entities, used for completely different purposes, 
a rare program needs to use all of them simultaneously, they may have 
different eraseblock size and other properties, they are just different. 
Yes, it happened to be that they are on one single chip, but they are 
still different.

Or we could look at them narrower:
b). A region is a kind of "appendix" to the flash chip, where the 
bootcode or whatever may be put. There is not more then one (or really 
few) regions per flash chip. There is only one big and main "data" 
region, and one or few small auxiliary regions.

I reckon that the reality is more like b). And in this respect I see 
your point. Indeed, what for should we spend more DRAM to describe this 
unworthy "appendix" (aka region) by a distinct software object? Let's 
push this all together!

I can agree with you *partially*, providing that chips like a). are 
*not* going to appear. Partially means that I only agree that there *may 
be* no reason to create a distinct MTD device for this poor appendix.

So I state: Ok, in b)-like chips, do not create a distinct MTD device. 
Let's invent something different. But this must not be in struct 
mtd_info anyway.

Do you see my points?

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.