On Tue, 14 Sep 1999, Julian Assange wrote:

> The code probably belongs more correctly in newfs. the rewriting
> of new cg's etc is complex enough such that it would be wise to
> take advantage of code that already understands (fsck_ffs) or does
> (newfs_ffs) it.

Well, okay, yes.  I guess the point I'm trying to make is not that the
code in fsck is not appropriate to the task (it is), but that the
*location* of fsck may not be, whereas the code could be adapted for use
in something other than fsck.  (IMO fsck is supposed to check the
filesystem for consistency, and fix it, and that's all.) 

So I'm suggesting a `libffs', that could be used to verify whether the fs
is okay (fsck), or make a new one (newfs), or change an existing one
(tunefs).  Ideally this filestore information would also be separate from
filesystem information, but integrated with an also-currently-nonexistent
caching block I/O library.

In short, it would be cool if

	- fsck_{f,l,ext2}fs all shared the same filesystem (not
	  filestore) code;
	- {dump,dump_,fsck_,new,tune}f?fs all shared the same
	  filesystem and filestore code;
	- the separation of function between the various utilities
	  remained clear.

						Konrad Schroder
						perseant@hhhh.org