From owner-freebsd-fs Thu Oct 28 9:49: 3 1999 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0B8D415252 for ; Thu, 28 Oct 1999 09:48:56 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA31120 for ; Thu, 28 Oct 1999 12:48:56 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 28 Oct 1999 12:48:55 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-fs@freebsd.org Subject: stupidfs - easily extensible test file systems? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm in the process of hacking up a stupidfs -- i.e., a minimal file system module that provides simplistic (i.e., stupid) implementations of all the relevant vnops and vfsops based on in-kernel memory. The purpose of stupidfs is to allow file system extension developers (like myself) to be able to add new vnops and implement them in a simple file system without having to deal initially with the issue of permenant storage in the file stores, distributed file systems, etc. It would be a poor-man's MFS (although perhaps more useful than MFS because it doesn't have the weight of UFS/FFS tangled up in it, which is what has stopped me from using MFS to do the same kind of testing), with it only really being useful for this testing purpose. However, as this will take a little bit to write, I thought I'd ask if anyone else has done this already? :-) Right now I pretty much have it to the point where I can see the directory structure, create files of up to 1k, etc, etc, but there's a fair amount more to do before it's useful. Those people working on ACLs and MACs for POSIX.1e have needed a test framework that doesn't involve seriously hurting themselves on the sharp edges of FFS and MFS, but that still allows them to actually see the results in a file system. Layering would be another option [if only it worked]. And even with layering, there are still complications in implementation -- more complicated, than saying "gee, let's extend the inode to have *this* structure in it" and just having it work as it backs to nothing and isn't tangled up in the idea of backing to something (e.g., MFS). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message