> Look, this is a fairly trivial item. You need to pick one of the two
> naming schemes. There are arguments for both. The benefits of either
> over the other are fairly insignificant.
> 
> Well, one has already been picked.

You misunderstand my argument.

My points are:

1)	If you are going to generate FS specific commands, they
	should be grouped by FS, such that the FS can be treated
	as a unit.

2)	The FS specific commands should be wrappered by a generic
	FS command that takes a -T argument, but does not require
	a -T argument if "fstyp" is implemented or if the device
	being referenced exists in the /etc/fstab already, such
	that iterating the /etc/fstab will identify the FS type.

3)	The best way to achieve grouping currently is with FS specific
	directories to contain the commands.

4)	The next best way to achieve grouping is by way of prefix,
	not a suffix, since it simplifies component identification
	without needing to determine subcomponent type.

5)	The worst way to achieve grouping (since it does *not*
	achieve grouping, it only achives differentiation) is by
	suffix.


I am not arguing for #4 or #5, which are each "one of the two naming
schemes".  I am arguing for the naming scheme you are omitting from
consideration by ignoring it:  #3.



> If you want to gratuitously reduce compatibility of FreeBSD with BSDI,
> NetBSD and OpenBSD, thats fine, but there is no rational reason to
> consider this to be so important that switching the order makes
> sense.

Neither is maintaining compatability with BSDI in what is essentially
a very system specific operation.  If you are arguing for compatability,
we should start with the argument type and parameter values used by
BSDI (who will certainly not change to be compatbile with us!) and
*correct* our *already bogus, by this measure* commands.  This would
remove a number of significant improvements which BSDI has failed to
pick up (in other words, it would be a Bad Idea).



> whereas I do see a larger learning
> curve, broken scripts and executables, and a dozen other reasons not
> to be gratuitously incompatible.

This assumes (INCORRECTLY) that scripts and users (ther than FS module
authors) will directly reference the FS-specific commands, rather than
referencing the wrapper commands which encapsulate the type-inference
entirely.  If this is truly your worry, then, again, the arguments and
parameters to the existing "name compatible" commands are sufficiently
different that they should be "corrected" (quoted, because I believe
the BSDI compatability argument is without merit until they exceed
FreeBSD in FS capabilities -- which they have not).


> > The only reasonably uniform mechanism for modular insertion/deletion
> > of supported file systems from an OS involves grouping the files by FS.
> 
> Your computer doesn't care what the names of the files are. Any
> reasonable package system (including the FreeBSD one) can handle sets
> of arbitrarily named files and add or remove them at will. Thats one
> of the reasons you have package systems.

What about the wrapper commands?  They, in fact, care, even if the
installation code does not.

Other than mkfs (no existing file type) and fstyp (must iteratively call
all FS specific fstyp's to determine), the wrappers can be expressed as
hard links to the shell script:

	#!/bin/sh
	#
	# link this to the command in question...

	CMD="$0"
	ARGS="$*"
	FSBIN="/sbin/fs"
	FSTAB="/etc/fstab"

	# parse out terminal command from CMD... at the same time,
	# get the FS type argument "-T <arg>" if specified
	FSCMD=...
	FSTYPE=...


	if test "x$FSTYPE" = "x"
	then
		# parse out device name to get FSTYPE; if operating on a
		# mount point instead of a device, get the type of the
		# FS mounted there, if any; otherwise, reverse lookup device
		# name in FSTAB to get the FSTYPE...
		FSDEV=...
		FSTYPE=`fstyp $FSDEV`
	fi

	# call the correct command for the correct type for the
	# provided device or mount point.  Each FS specific mount
	# will ignore the "-T" option, so it is OK to pass the full
	# argument list without parsing it out.

	$FSBIN/$FSTYPE/$FSCMD $ARGS

	# return it's return code as ours...
	exit $?


The fstyp can be expressed as:

	#!\bin\sh
	#
	# fstyp [-v] special
	#
	# give the name of the FS

	FSBIN="/sbin/fs"
	ARGS="$*"

	# parse out special device argument to avoid passing -v to
	# the iterative calls in case there is more than one match
	FSDEV=

	# change directory to avoid having to remove the bin path
	# prefix in the for loop...
	cd $FSBIN

	FSTYPE=""
	FOUND="NO"

	for i in *
	do
		# for each FS for which an "fstyp" exists..
		if test -x $i/fstyp
		then
			# call fstyp without extra arguments (-v, if present)
			$i/fstyp $FSDEV > /dev/null
			if test "$?" = "0"
			then
				# if found and already found, ambiguous
				if test "$FOUND" = "YES"
				then
					# found more than one
					FOUND="AMBIG"
				fi

				#if found and not already found, then found
				if test "$FOUND" = "NO"
				then
					# found one
					FOUND="YES"
					FSTYPE="$i"
				fi
			fi
		fi
	done

	# no matches
	if test "$FOUND" = "NO"
	then
		echo "unknown_fstyp"
		exit 1
	fi

	# too many matches
	if test "$FOUND" = "AMBIG"
	then
		echo "unknown_fstyp"
		exit 2
	fi

	# success; one match.  Call with extra arguments (-v), if any...
	$FSTYPE/fstyp $ARGS

	exit 0


> > Ideally, the grouping should be done on a directory basis rather than
> > a prefix basis so that only a single point of adjustment is necessary
> > to perform the insertion or deletion.
> 
> Your proposal would have made sense BEFORE everyone else picked a
> scheme.

My proposal was MADE "BEFORE everyone else picked a scheme"... it was
made in 1993.  Your proposal would have made sense if everyone hadn't
been ignoring my good advice when they picked a scheme.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.