Subject: Re: "tfs" and other filesystems with very short names
To: None <>
From: Greg A. Woods <>
List: source-changes
Date: 09/22/1998 20:24:52
[ On , September 22, 1998 at 17:36:37 (-0400), wrote: ]
> Subject: Re: "tfs" and other filesystems with very short names
> Very good question.  But there are two.  We call it Coda here so
> the directory is coda.  Then I looked at all the fs's and some used
> fs in the name of their methods and some did not; it was pretty evenly
> split.

I should have been specific -- I meant in the kernel's namespace
(including both symbol space and source filesystem naming)

Let's see (this from directories only in the kernel):

	With "fs" suffix:	Without "fs" suffix:
	=================	====================

	adosfs			coda
		deadfs			fdesc
		fifofs			portal
		(genfs)			union

That's about 16 to 4 if you count real filesystem types.  I've not (yet)
collected any stats to compare how consistent the symbol-naming is
inside the code (but if it's as bad as the device driver universe, then
it's pretty bad).

Of course if you look at the various sbin/mount_* directories in the
user-land source:

	With "fs" suffix:	Without "fs" suffix:
	=================	====================

	mount_ex2fs			mount_ados
	mount_ffs			mount_cd9660
	mount_kernfs			mount_fdesc
	mount_lfs			mount_filecore
	mount_nfs			mount_msdos
	mount_procfs			mount_null

you get a slightly different perspective.

It's a bit harder to change user-land, and indeed there's less need to
change user-land because it's much more obvious that you're dealing with
a filesystem when you use the "fsck", "newfs", "mount", etc. commands.
(I say only a "bit harder" because users rarely use the
<operation>_<type> commands directly.

If I were in my own universe and cared not for history I'd rename all
the directories and symbol names in the kernel to have the "fs" suffix
(and I'd probably shuffle some of the fs directories around and perhaps
make a sys/fs sub-directory to put them all in), and I'd probably also
add the "fs" suffix to the the filesystem type-name suffixes on the
user-land tools (and I'd move all the <operation>_<fstype> commands into
a directory that's not normally in any user's path (i.e.  not even in
root's path), such as /libexec.

But then I'm very draconian about naming conventions and directory
organization....  Unix has always been a bit quirky and inconsistent,
something that comes naturally to a system developed by a community in a
primarily consensus-driven manner.

[Yes the "fs" suffix is redundant when you know you're dealing with
filesystems, but "mount_n" and "mount_f", etc. or "fs/n" and "fs/f" look
pretty funny, at least to me.]

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>