Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Dec 1996 15:11:35 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.)
Cc:        terry@lambert.org, freebsd-hackers@freefall.freebsd.org
Subject:   Re: Other filesystems under FreeBSD
Message-ID:  <199612152211.PAA24071@phaeton.artisoft.com>
In-Reply-To: <32B49D07.3A62@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at Dec 15, 96 04:51:19 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> I have this crazy dream that I could, one day, mount SCO, Linux, and
> Solaris FS's under FreeBSD *and* run all this apps transparently by
> emulating.
> I now have more documentation about SCO filesystems, and HPFS: these two
> are also supported (partially) by Linux. What I really don=B4t have is
> documentation about FFS.
> Since fbsd seems to be ill suited for other filesystems, should "we" try
> to implement a standard Linux filesystem and derive the others from it,
> or should *we* try to use more documentation than Linux sources, and try
> to implement them from our VFS?
> 
> 
> Pedro.
> 
> Some years ago, Terry Lambert wrote:
> > There is nothing "magical" about these implementations, except our VFS
> > interface is still pretty poorly suited to adding new FS's without a
> > lot of work to get around layering problems, a lot of code which has
> > to be duplicated per FS which belongs in upper layers, and a full
> > kernel recompile because the vfs_init still gets its side from the
> > UFS vnops and vfsops structures intead of from a sizeof() in vnode_if.c.

This is out of context.  The article you are quoting was discussing
this either in the context adding new VNOPS, or in the context of
adding multiple name spaces for VFAT/NTFS/HPFS support.

You also seem a bit confused about what I said, vs. what I meant.
This is probably my fault, so I'll clarify a bit.


FreeBSD is well suited to other file systems.  What I was discussing
was a number of small changes to the mechanism to seperate the
implementation from the instantiation.  Basically, I wanted to be
able to simplify the code I needed to write to write a new FS, even
more than it is already simplified over that for Linux.  This is not
the same thing as the code being impossible without the changes,
only "more difficult than it would be in Terry's ideal world".

The BSD VFS interface is much, much better abstracted than the Linux
VFS interface.  Part of this is because the Linux interface has been
rigidly defined in order to meet the LGPL criteria for kernel modules
that are not GPL/LGPL themselves calling kernel functions, but yet not
technically being part of the kernel.  Part of it is the way the VFS
bottom end interface to the buffer cache and disk I/O has been grown
organically in Linux.  And part of it is that the Linux VFS expects
only a single consumer, so the top end interface is not well seperated
from the system call interface (this is also the reason it does not
yet have a kernel NFS server).  Usage of region prevalidation, besides
leaving nasty security holes in the SMP and kernel multithreading cases,
is very system-call consumer specific.

The FFS is probably irrlevant for what you want to do... it's overly
complex for simple sample code.

Actually, you probably want to implement the SCO FS's seperately.
For this, the monolithic FS's would be a better example of cache
and VFS top end interfacing than the UFS derived FS's, which share
code in non-obvious ways.


Clearly, this would be easier for you if the FreeBSD VFS interface
was more rigidly abstracted than it is at the top end, and the FS
physical media interfaces were better documented than they are
(both of these are problems which are being addressed).  But even
though I don't think they are done (I have high standards), they
beat the Linux abstractions (which are non-existant) cold.



If you find you have specific questions on implementation that aren't
answered in the Heidemann thesis in the FICUS project directory on
ftp.cs.ucla.edu, or in the book "The Design and Implementation of the
4.4BSD Operating System", then send me mail.  If I don't already
have the answer archived, I will find one for you (the SCO FS's are
rather important; HPFS has been dropped from BT 4.x and so is about
as important as OS/2: not very).

					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612152211.PAA24071>