Rockbox mail archive
Subject: Re: disk write code - another bug
From: Greg Haerr (greg_at_censoft.com)
: I recommend you post your intentions before spending many hours rewriting
the code. You still have not shown us how your code will work, and be
substantially simpler. The only thing I have seen so far is your
consolidated buffer code. And you haven't told us how you will change it so
it does not hurt performance.
OK. I've spent most of my time understanding how the current
implementation works. I'm doing this for fun, as you are -
if you're interested, I will describe in more detail how a slightly
changed implementation would be superior. If you're not really
interested, I'll back off.
I would like to see
the FAT32 implementation made simpler, without having to
handle buffering special cases in three different places; that's
my intention. This is because the filesystem and threading kernel
form the basis of the rockbox system, and I think we're almost
there to an elegant implementation for both ;-)
I've found a couple of other places where the current code
is not correct; I'll forward this information, it's not critical code.
: Lets avoid repeating the font incident we had earlier, where one person
spent a lot of time rewriting code in isolation and then became angry when I
didn't accept his big patch.
I agree completely. Certainly the FAT32 driver is the last thing
we'd want to modify in a big way without a lot of testing. Actually,
this is why I chose (for the fun of it) to implement the buffer-cache
scheme without optimization for the first round - because I wanted
to keep the filesystem running, which is far more important IMO
than submitting a wholly new design. This iterative process is
something I use a lot in my designs.
Page was last modified "Jan 10 2012" The Rockbox Crew