Martin,
I've been using Yaffs on linux for a few years now. You can see
me prattling on about MTD issues on the list. I am old-time unix
hack and netbsd is one I'm familiar with and use daily.
I while back I briefly discussed the possibly of porting Yaffs to
NetBSD with Charles but I've not gone anywhere with it.
I just wanted to reply and say that if you would consider
contributing your upper VFS layer to the project, that would be
welcomed by me at least. Your lower layers for i/o to the NAND
device may be of general use too, even if they are specific to
your hardware; they could serve as a sample implementation.
Cleaning-up the general structure of Yaffs is something that has
been discussed. So if you find you have to fix up headers, rename
macros, add abstractions etc., I think that's all moving in the
right direction. Having versions of Yaffs branch and diverge
doesn't help anyone in the long run. And there's nothing
better than a new port to flush out issues that, once addressed,
generally improve code quality and program structure.
As a side: if Yaffs were used only in the loadable module form on
NetBSD, could it not be use/licensed under the GPL?
-imcd
On Monday 29 October 2007 16:41, 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?
>
> 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
(text/plain)