I read the post.  I know we can't use the code.  Perhaps I'm wrong, but as I
understand it there's a lot more to do than just the implementation -- ie
the design of the file system.  My point was then twofold:

1) that design has been done in (presumably) a very good fashion.  We don't
need to duplicate it, even if we do need to duplicate the code.

2) having flash file systems in NetBSD and Linux be compatible is a Good
Thing.  However, I actually think that in this case compatability with the
Sega file system is more important, as was pointed out earlier.

Further, I think I'll just shut up now...

Evan Daniel

-----Original Message-----
From: Jason R Thorpe [mailto:thorpej@zembu.com]
Sent: Thursday, March 15, 2001 6:53 PM
To: daniele@ncssm.edu
Cc: port-dreamcast@netbsd.org
Subject: Re: X-Box and PS2 port candidacy


On Thu, Mar 15, 2001 at 03:31:50PM -0500, daniele@ncssm.edu wrote:

 > Yes, but not on a NetBSD Flash FS, unless I haven't heard about it, and I
 > think it would have come up already.  I think that FS design is fairly
 > difficult (I have no experience here, mind), and flash particularly so
 > because of the limit on number of writes, and if the work is done and
 > useable, all the better.  If it's not usuable, then I guess it needs to
be
 > redone.  No offense intended whatsoever;  I apologize if any was taken.

Did you read my message?  We can't use the Midori *code* for a couple of
reasons:

	(1) It has an incompatible license on it.

	(2) Linux file systems have a COMPLETELY different interface to
	    the rest of the kernel than BSD file systems do.

Point #2 means that we'd have to rewrite a vast majority of the code
*anyway*.

I did say that we could study the Midori flash file system, understand how
it works, and then implement the ideas in a file system for NetBSD.  Hey,
and some of us have done file system work before, even (I spent 5 years
working for a distributed supercomputing research center, a fair amount of
the time I spent working on mass storage problems, including file system
issues).

There are other things to consider in a flash file system other than the
limited number of write cycles (and there are pretty obvious techniques
for dealing with that anyway).  The most important one, esp. for embedded
systems, is something called "run-in-place".  Consider the case of a
memory-mapped flash... copying a read-only VTEXT page from the flash to
a RAM page seems pretty wasteful if you can simply map the flash page
directly, eh?

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>