Hi,

Longtime yaffers may remember me from a couple of years ago when I was
at Palmsource and briefly helped out with yaffs on linux.

I've moved on and am now developing NetBSD for smartphones at Danger but
have found my way back to yaffs, since NetBSD lacks a solution for NAND
filesystems.

Basically, I've written the NetBSD equivalent of the Linux VFS layer for
yaffs and am now in the process of debugging it.  If we decide to go
with yaffs, rather than our port of Reliance/FlashFx from Datalight, we
will license yaffs direct from Aleph1, and use my layer instead of
modifying the Linux layer, since we can't use GPL-ed code in this
project.

But that's not why I'm here. ;)

We're using yaffsfg2k.c, yaffs_ecc.c, yaffsfs.c, yaffs_guts.c,
yaffs_packedtags1.c, yaffs_tagscompa.c, yaffs_tagsvalidity.c,
yaffs_nand.c, yaffs_checkptrw.c and yaffs_qsort.c. We'll probably
eventual drop yaffs_qsort.c  We're also using devextras.h,
yaffs_checkptrw.h, yaffs_ecc.h, yaffs_guts.h, yaffs_nand.h,
yaffs_packedtags1.h, yaffs_packedtags2.h, yaffs_qsort.h,
yaffs_tagscompat.h, yaffs_tagsvalidity.h, yaffscfg.h, yaffsfs.h,
yaffsinterface.h and yportenv.h

In porting to NetBSD, we're finding three different kinds of bugs:

1) porting bugs -- which I'd like to discuss later in this email
2) 'real' bugs -- which I think we should treat the same way anyone
would: by presenting on this list
And
3) coverity bugs.

For those not familiar with it, Coverity is a static code analyser that
finds certain kinds of programming bugs. Our first run of Coverity on
our yaffs port to NetBSD found about 40 of these "bugs". Coverity, of
course finds bugs that aren't really bugs (false positives) and bugs
that are "can't happen" bugs that could happen if certain conditions
appear, but that those conditions can't happen in real life, in addition
to finding real bugs, so it is likely that there are far fewer than 40
of these coverity bugs in yaffs.

My guess is that we should treat coverity bugs like 'real' bugs. That
is, if we examine a coverity bug report and believe it to be a real bug
in yaffs, we'll just bring it up on the list.  Does that seem
reasonable?

And now, the meat of the email

The biggest 'porting' bug we've found so far is that yaffs uses the
list_head macros from the kernel and contains its own version of those
functions in devextras.h.  This conflicts with the way in which those
are macros are defined in NetBSD, since we need to include the NetBSD
kernel header that defines them, and so we get conflicting definitions.

The approach we've taken was to use a *big* hammer: we simply added
yaffs_ in front of all the macro names in the code we get from yaffs.

I'd like to suggest that change for the cvs tree, and contribute a patch
with it, or work to figure out another solution if you'd like.

Beyond that large change, so far the only other changes I've made for
portability is to add some initializers so that gcc would shut about
about unitialized variable warnings, since NetBSD kernels are built with
warnings as errors. Do you want that sort of change back as a patch?

Also, I've just picked up the fsx test, and will start trying it on
NetBSD as soon as our VFS layer is stable enough.

We're also running a couple of file system benchmarks, most notably
bonnie as stress tests, and will report any problems we find.

It's good to be back. ;)

Marty