Hi Marty

Great to hear from you again.



On Tuesday 30 October 2007 09:41:44 Martin Fouts wrote:
> 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?

All code checking is Good Stuff. I am particularly interested in Coverity 
since I've been hoping for Coverity feedback for a while.

>
> 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.


That yaffs-ifying the macros sounds like good sense to me: far better than 
getting macro-wars. It sure improves portability.

>
> 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?

Yes please.

>
> 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.

Cool. All testing seems to stress out different angles and all testing is 
Good.
>
> It's good to be back. ;)

Even better to have you back!

-- Charles