From owner-freebsd-fs Wed Jun 3 08:36:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA02267 for freebsd-fs-outgoing; Wed, 3 Jun 1998 08:36:42 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from gatewayb.anheuser-busch.com (gatewayb.anheuser-busch.com [151.145.250.253]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA02029; Wed, 3 Jun 1998 08:35:26 -0700 (PDT) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewayb.anheuser-busch.com; id KAA27771; Wed, 3 Jun 1998 10:34:00 -0500 Received: from stlabcexg003.anheuser-busch.com( 151.145.101.158) by gatewayb via smap (V2.1) id xma027648; Wed, 3 Jun 98 10:33:53 -0500 Received: by stlabcexg003.anheuser-busch.com with Internet Mail Service (5.5.1960.3) id ; Wed, 3 Jun 1998 10:32:24 -0500 Message-ID: <31B3F0BF1C40D11192A700805FD48BF9017765D7@STLABCEXG011> From: "Alton, Matthew" To: "'hackers@FreeBSD.ORG'" , "'FreeBSD-fs@FreeBSD.ORG'" Cc: "Smallie, Scott" Subject: Filesystem Development Toolkit Date: Wed, 3 Jun 1998 10:33:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hackers, My recent excursions into the wonderful world of filesystem development have led me to embark on the following Mondo Project which is currently in the lex-spec + stubs phase. The project spec follows. Well, it started out as one anyway, but turned into a sort of polemic rant. I wrote it in the throes of trad- itional development :-) Please help me come up with good ideas. Yes, I'm going to copyleft the software. I just can't stand the thought of Bill's henchmen holding my slightly modified code hostage in their nasty ten- tacles. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ $Id: SPEC,v 1.3 1998/06/03 00:09:30 matta Exp matta $ Filesystem Development Toolkit ============================== The Filesystem Development Toolkit (FDT) is software designed to ease the task of implementing, testing, and debugging filesystem designs. Traditional filesystem development is unduly complex. The procedure involves: 1) Design phase - The fundamental structure and properties of the filesystem are defined; 2) Coding - The filesystem code and operating system kernel interface code are written; 3) Testing - The filesystem modules are loaded into system space and run with superuser privileges; 4) Debugging - Problems detected in the testing phase are traced to root causes in the coding and/or design phases and are remedied. This procedure is fraught with alleviable difficulties. The coding phase nec- essarily involves a detailed knowledge of the inner workings of a specific oper- ating system. Such knowledge is often irrelevant to the purpose of the develop- ment effort. The filesystem interface particulars vary radically between oper- ating systems so that the code must be altered substantially for each new de- velopment platform. Testing new filesystem code invariably involves destabil- izing the operating system running on the test platform so that a machine must be dedicated to testing. The debugging phase is egregiously difficult as oper- ating system debugging is inherently more difficult than application debugging. Each cycle of the process may necessitate a reinstallation of the operating system due to media corruption caused by buggy filesystem code. A non-root user is not able to test a new filesystem design at all. Many of these problems are rendered geometrically more difficult when the filesystem in question is of the distributed variety and requires multiple network nodes for testing pur- poses. All of these difficulties may be relieved to various degrees by simply moving the development cycle entirely into user space. The difficulty involved in developing a new filesystem would then be on the order of that involved in app- lication development. The problem of "porting" the new filesystem to another operating system, while still difficult, would at least be distinct from the development cycle. The FDT provides a simulation environment for developing filesystems in user space by effectively "stepping down" the levels of the operating system. The filesystem under development actually exists as a regular file which the FDT manipulates. This regular file is in effect a "disk image" containing a bit- for-bit likeness of an instance of the filesystem under development. The FDT provides the layer of abstraction necessary to create filesystem objects in the disk image. Concurrent access may be controlled through file permissions and ... ... ... sfc - Simulation Fileystem Control program. Command-line interface for use in filesystem prototyping. Commands: ![cmd [args ...] ] - Shell command. Execute cmd in a subshell. mkpf < -s size pf_name > - Make prototype file. Create a zero-filled file named `pf_name' of `size' bytes analogous to a mass storage device. mkfs < pf_name > - Make file system. Create a bit-pattern analogous to a filesystem on the prototype file named `pf_name'. mount_lfs < pf_name > - Mount file system. Reset `pf_name' clean bit and enable read and write operations on `pf_name'. Analogous to mounting filesystem named `pf_name' on mount point `pf_name'. fsck < pf_name > - File system check. Check and optionally attempt to correct inconsistencies in bit-pattern on file `pf_name'. df [ pf_name [ pf_name ... ] ] - Summarize disk free space. Display summary of free space per prototype file argument. du [ pf_name [ pf_name ... ] ] - Summarize disk usage. Display summary of space usage per prototype file. cp < source dest > - Copy filesystem object from source to dest. `source' and `dest' may be files or bit-patterns within a prototype file. mv < source dest > - Move filesystem object from source to dest. `source' and `dest' may be files or bit-patterns within a prototype file. mknod < node b|c|u major minor > - Make device special file. Make ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 matthew.alton@anheuser-busch.com alton@plantnet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message