On Thu, 22 Sep 2005, Charles Manning wrote:
> On Thursday 22 September 2005 04:13, Sergey Kubushyn wrote:
>
> > OK, now for the yesterday's torture test. First of all, YAFFS failed
> > miserably. Now about setup and results.
>
> <Sigh>
>
> I did not expect your test to last very long.
>
> Those ecc errors you talk about are: "YAFFS TELLING YOU THAT THE
> MTD/YAFFS
> INTERFACE IS WRONG AND DATA IS GETTING SCREWED UP"
That FS mounted as root FS is not giving errors. The second one does.
> Now I've tried to tell you this a few times, but it seems you do not
> wish to
> listen. If you will not listen then we can't help you and further
> responses
> to your postings is a waste of time.
I'm trying to help.
> YAFFS is telling you there is a problem. Focus on the problem. There
> are
> numerous posts in the past on how to look into the issue and that this
> is
> combined YAFFS/mtd effort to get things going. Many people have had to
> tread
> this path before. It is far from ideal, but we're working on improving
> it
> (currently waiting on mtd fixes)
OK, as I understand you're trying to say that every single kernel is unique
and there is no way to fix that yaffs/mtd problem because of that
uniqueness?
Can you simply tell something like "When using its internal ECC YAFFS uses
such and such MTD functions and expects that they would return the raw NAND
data?" It would be very easy to fix those functions instead of trying to
understand what YAFFS is trying to do and what MTD think of that? I simply
can't believe that it requires two years to fix a couple of functions in
MTD. Name those functions and I'll fix them myself.
Would you also be so kind to disclose what mtd fixes you're waiting on? MTD
code is not that big and there is no reason to drag that same matter for
years. Please say it loud and clear: "We do use the following functions from
MTD and expect them to behave in such and such way." Then MTD can be fixed.
As for now there is no other requirements than that old mantra "MTD is bad."
It's easy to fix any code if one knows what to fix. Having those errors
still not fixed after at least two years clearly indicates that nobody even
tried to do that. I don't think anyone has enough time to grok how the
entire yaffs/yaffs2 works and anticipate what it supposed to expect from MTD
and whatever else. MTD, on the other hand, is as simple as a shovel so if you
want its blade to be bent in some particular way, just whistle.
Generic MTD utilities (nanddump, nandwrite etc.) do NOT have any problems
getting anything they need from MTD. That means they DO know how to ask MTD
layer for what they want. YAFFS, on the other hand, has been having problems
for as long as the list goes. May be it's time to finally fix something, be
it misbehaving MTD or buggy YAFFS? Such a thing as a filesystem should NOT
require any black magic or monkey drum dances, it MUST compile and work
right out of the box. Let's start with 512-byte devices that are more common
now and code for those is more of a legacy. Don't ask MTD for any funny
tricks, just ask it to read and write data exactly as it's instructed to do
and do everything else yourself. Make at least that work out of the box
without resorting to "MTD is bad." Than formulate the requirements for
anything missing or misbehaving in MTD so that could be written or fixed and
you will be able to finally show that yaffs2 in all its shine and glory.
Define all the data structures and check they match those from MTD. I'm
pretty sure they don't and this is the principal cause of all that sorry
state. One more time - MTD is simple as a shovel. It's not a filesystem,
network stack or something like that. It is just a mere physical device
driver. If it does not work as it supposed to please point to its bugs. THE
bugs, not bugginess.
> Unfortunately these yaffs/mtd problems go all the way through to the
> yaffs
> tools too. That is why the mkyaffs and mkyaffsimage have problems with
> some
> mtds.
What is "some mtds?" Are there many of them? I do only know one, that in the
Linux kernel. If you mean some particular snapshot happened to work with
YAFFS, NAME it. Then, mkyaffsimage can NOT have ANY problems with ANY mtd
because it doesn't use MTD at all, it simply generates some image of a
predetermined format no matter MTD or not. It doesn't even know of MTD
existance.
Then, when using a bare YAFFS, without NAND ECC and tools--just erase the
flash, mount it and copy files to the mounted filesystem--you mean MTD
somehow changes data it receives from yaffs when writing files and send back
to yaffs when reading them? No, that's NOT a case, I clearly see that it
gets back exactly what it wrote. And MTD tools (e.g. nanddump) confirm that
NAND itself has exactly the same data YAFFS instructed MTD to write at
exactly the same locations it asked MTD to put it at.
> I would like to suggest that either:
> * accept the above and try to be constructive and work the problem from
> both
> yaffs and mtd sides, and actually listen to the advice you are getting.
> *withdraw yourself from the list and find some other creative outlet
> for your
> energy.
I AM trying to be constructive. And NO, I am NOT getting any advice. "Fix
your MTD" is NOT an advice of any kind. It's not MY MTD, it's what every
single Linux user have. There is NO way to work the problem from either
yaffs or MTD side because you do NOT tell what the problem is. One more
time: please, list all the functions from MTD you want to use with all the
data structures passed and returned defined and the expected result and
those "mtds" will be fixed in no time if there is anything to fix there.
It is the noble decision to make something for a community. And nobody
forces anybody to do so, it's a matter of personal choice. But if one
already made such a decision he also took some moral responsibilities.
Remember, we are responsible for all we tamed...
OK, if you don't need any help and prefer to "fix mtds" forever and to keep
your creation in diapers for years, go for it. I'd rather withdraw from the
list.
I just tried to kick somebody's ass to make them do something. Looks like it
doesn't make any sence, nobody here wants to solve problems.
---
******************************************************************
* KSI@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
(text/plain)