Date: Sun, 16 Jul 1995 11:53:58 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: freebsd-current@FreeBSD.org Subject: Re: Move mt(1) to /bin? Message-ID: <199507161853.LAA09001@gndrsh.aac.dev.com> In-Reply-To: <199507161625.SAA20762@uriah.heep.sax.de> from "J Wunsch" at Jul 16, 95 06:25:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>
> As Rodney W. Grimes wrote:
> >
> > > Unless somebody objects, i would going to move it some day.
> >
> > I don't want to go doing this on a binary by binary as the need
> > comes up. There are several things that given the same above
> > conditions should be moved to /, and several that could move
> > the other way.
>
> Ok. NB: i've made the above threat since this seems to be the only
> way to get opinions from other folks here... This is not to say mt(1)
> wouldn't be needed, it is. While ``mt fsf'' could also be performed
> by ``dd if=/dev/nrst0 of=/dev/null'', things like ``mt blocksize'' and
> ``mt density'' cannot be emulated.
I don't have a problem with the technical reason that mt should move
to /bin (or more probably /sbin since only root and operator class
users cat access a tape device anyway) and agree this is one of them
that should be static and on / _if_ the critera for being on / says
``Anything needed to restore a system from tape'' as one of it's items.
The current man 7 hier is rather ambigous:
/bin/ user utilities fundamental to both single-user and multi-user
environments
/sbin/ system programs and administration utilities fundamental to both
single-user and multi-user environments
I've almost growen sick of the /bin vs /usr/bin problems and maybe we
should do what Bruce is doing and just make _every_ thing shared and
move the libraries onto /lib :-) And while we are at it /usr/bin -> /bin
and /usr/sbin -> /sbin. (That would be a 13MB increase for the shared
/usr/bin and /usr/sbin, 3MB for /usr/lib/*.so.*, and I don't know what
the shrink for shared /bin and /sbin is, but I seem to remeber Bruce saying
that it makes the /usr/lib/*.so.* actually a 0 size increase to the
root partition if you run all of /bin and /sbin shared, but I don't think
we want all of it shared (/bin/sh is a bad things to have shared due to
frequence of invokation and shlib startup times).
I have seriously digressed from the original topic :-(, I'll move mt
now, if no one objects to the folling moves:
/usr/sbin -> /sbin
bad144 (needed to fix your disk before you can restore from tape),
chown (needed to fix and build /dev entries so you can mount your disk
routed (needed to find routes to remote hosts before mounting nfs /usr
or using a remote tape device to restore /usr from)
sysctl (needed to tweak settings frequently so you can get to things
over the network so you can get your system back to life)
/usr/bin -> /bin
awk (needed by /dev/MAKEDEV to rebuild several /dev entries that
give you serious headaches if you try to do MAKEDEV all without
/usr around, could be coded around with sh probably)
chflags (So you can fix a permission problem that prevents you from
restoring some part of / or /usr.)
mt (So you can set the density on /dev/st0 to read your backup tape).
I am going to stop now... but you get the idea... I have a very large
pile of requests to move stuff to /bin, but not a one to go the other
way :-(.
IMHO, probably should not do these, though they have been requested
at one time or another:
kbdcontrol (Yes, I actually have a pending request to make this usable
in single user mode, mainly to handle backspace key mapping,
and load full keymap files, but that means /usr/share/syscons
would need moving too :-()
> > Also don't move things around with cvs remove/cvs add, contact me for
> > a repository copy, otherwise history information is lost into the Attic.
>
> Of course. I didn't think about doing this myself. I know that this
> is the kind of stuff to leave for our Repository Meister. ;-)
>
> --
> cheers, J"org
>
> joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/
> Never trust an operating system you don't have sources for. ;-)
>
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507161853.LAA09001>