Date: Tue, 25 Mar 1997 17:22:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: perry@piermont.com Cc: terry@lambert.org, thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, hackers@freebsd.org, port-i386@netbsd.org, darrenr@cyber.com.au Subject: Re: how to name fs specific programs Message-ID: <199703260022.RAA26405@phaeton.artisoft.com> In-Reply-To: <199703252319.SAA02811@jekyll.piermont.com> from "Perry E. Metzger" at Mar 25, 97 06:19:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703260022.RAA26405>