Linux 2.6.23-rc8 for OpenMoko
hch at lst.de
Mon Oct 1 00:31:27 CEST 2007
On Sun, Sep 30, 2007 at 08:05:27AM -0300, Werner Almesberger wrote:
> Christoph Hellwig wrote:
> > Are the openmoko developers to time contrained to send it upstead
> You hit the nail right on its head :-( Well, I haven't even had time
> to help with OpenMoko mainline for some months now, so it's really
> just Harald who's in charge of that, and he's in charge of quite a
> lot of things ...
So do you guys need some help dealing with rmk's patch queue? This
kind of reshuffling patches and responding to comments is what I do
for relaxing when I'm too tired of real work :)
> > Not only is yaffs2 an utter piece of crap,
> Ah, you mean code quality or are there also known bugs or design
> flaws ?
I can't comment too much on the actual ondisk format because I'm not
an expert on flash memory, but many revisions it went through for
different technologies are at least a little alarming. Also the
ondisk layout for hardlinks doesn't look to very encouraging. As
far as the actual code is concerned it's a complete nightmare. The
read/write path is buggy in more ways than it has lines of code and
needs to be ripped out and replaced by new code entirely, with much
more use of existing standard linux functionality. It's not that
dramatic on the namespace side, but that code has quite a lot bugs
in the software design aswell as layering problems. Add to that
"features" like variant symlinks that have been NACKed multiple
times because they're better implemented using bind mounts and you
get a really nice cocktail ;-)
> > but it's also not used at laest on my neo (fortunately!).
> We use it on HXD8, which has tons of NAND.
How large is 'tons'? If it's really going into the Gigabyte range
I'd suggest looking at logfs, otherwise a recent jffs2 with the
scalability improvements from olpc should be fine.
More information about the openmoko-kernel