Lets get serious here.

4.4lite introduced the entire mount_${fs} thing.

It is arguable whether it is better to say ffs_mount or mount_ffs, but
frankly it doesn't matter much, and having picked one there is no good
reason to break people by switching back.

This isn't the sort of thing that is so critical that there is a
reason to be gratuitously incompatible with what another BSD is doing,
and 4.4lite set the precedent.

Perry

Terry Lambert writes:
> >  > Curious: why aren't they using it as a prefix instead of a suffix?  It
> >  > would seem to make more sense as a prefix, for all sorts fo string
> >  > manipulation reasons, including argv[ 0] and _ replacement with 0
> >  > for string split issues...
> >  > 
> >  > Is it just that SVR4 does it with prefixes, and NIH rules?
> > 
> > ....there was already a (weak) precendent in BSD for suffixes... c.f.
> > "newlfs".
> > 
> > Of course, I don't recall checking what SVR4 did, either.  It's
> > not clear that it matters that much.
> 
> Really?  Which do you prefer?
> 
> The list to show by command?
> % ls /sbin/fs
> clri_cd9660	clri_ffs	clri_kernfs	clri_lfs
> clri_mfs	clri_msdos	clri_nfs	clri_null
> clri_portal	clri_procfs	clri_umap	clri_union
> dump_cd9660	dump_ffs	dump_kernfs	dump_lfs
> dump_mfs	dump_msdos	dump_nfs	dump_null
> dump_portal	dump_procfs	dump_umap	dump_union
> 
> ...
> 
> 
> Or the list to show by fs?
> % ls /sbin/fs
> cd9660_clri	cd9660_dump	cd9660_fsck	cd9660_fstyp
> cd9660_mount	cd9660_newfs	cd9660_restore	cd9660_umount
> ffs_clri	ffs_dump	ffs_fsck	ffs_fstyp
> ffs_mount	ffs_newfs	ffs_restore	ffs_umount
> 
> ...
> 
> 
> If I had my way, it'd look like:
> % ls -R /sbin/fs
> cd9660		ffs		kernfs		lfs
> mfs		msdos		nfs		null
> portal		procfs		umap		union
> 
> /sbin/fs/cd9660:
> clri		dump		fsck		fstyp
> mount		newfs		restore		umount
> 
> /sbin/fs/ffs:
> clri		dump		fsck		fstyp
> mount		newfs		restore		umount
> 
> ...
> 
> If I want to add a new FS, I add /sbin/fs/$(NAME) and /lkm/$(NAME)_mod.o
> and it all just works.
> 
> 					Regards,
> 					Terry Lambert
> 					terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.