Konrad Schroder <perseant@hhhh.org> writes:
> It counds good to me; my only concern would be that the fact that
> newfs_ffs is currently called `newfs' didn't cause any problems; since
> there are a lot more of them than options to mount(8).  Does the new
> newfs just pass on all its options besides fs-type to newfs_xxx, or do the
> options to newfs_ffs no longer directly work with newfs? 

Big ball o' hair.  in my opinion bad idea to go there.

Really, there's a reason to have mount vs. mount_*.  there, you need a
standard name and a standard set of arguments for the invoked
programs, so that you can invoke them easily in an automated manner.

if you're running newfs or newlfs or whatever in an automated manner,
you're doing so for a specific file system type (because that's the
one you want).  there's no real cause to have a generic wrapper, as
far as i'm concerned.


further, the initial assertion that a bunch of new newfs-like programs
have been added recently isn't really true.  8-)

i don't see this as a growing problem.  if some people really do
perceive it as a growing problem, then maybe we need to rename the
programs, e.g. newfs -> newfs_ffs (but that doesn't really work, you
kinda want the name 'new_ffs', which is just evil), etc., but
backward-compatiblity links should be retained because there's just no
reason to change them.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.