From owner-freebsd-hackers Sun Dec 15 14:34:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA08236 for hackers-outgoing; Sun, 15 Dec 1996 14:34:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA08225 for ; Sun, 15 Dec 1996 14:34:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA24071; Sun, 15 Dec 1996 15:11:35 -0700 From: Terry Lambert Message-Id: <199612152211.PAA24071@phaeton.artisoft.com> Subject: Re: Other filesystems under FreeBSD To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.) Date: Sun, 15 Dec 1996 15:11:35 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freefall.freebsd.org In-Reply-To: <32B49D07.3A62@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at Dec 15, 96 04:51:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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.