svn commit: r365643 - head/bin/cp

[Konstantin Belousov]

On Wed, Sep 23, 2020 at 11:23:51AM -0600, Warner Losh wrote:
> On Wed, Sep 23, 2020, 10:56 AM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
> wrote:
> 
> > > cp is already fixed, people are still feeling the fallout of being
> > > within those revisions and needing to bootstrap their own cp. We can
> > > reduce the number of components these invocations rely on trivially to
> > > shell built-in mechanics, why not do so?
> >
> > I would even go further, I would like to see the dependency on
> > /dev/null removed from the build, and the boot process.
> >
> 
> A worthy goal, but one I'm afraid is out of our reach. A quick grep shows
> just over 200 instances of /dev/null in the Makefile and mk file (800 if
> you don't filter Makefile.in and Makefile.am). Maybe a third of those are
> due to tests and other false positives. It would be quite the effort to
> eliminate them all. And /dev/tty and /dev/zero likely will be troublesome
> too, as they are used by running programs.
> 
> and how would you throw away output you know is bad / bogus without
> /dev/null?
> 
> >From the build because it means I would no longer have to
> > mount /dev in my chroots, and from the boot because I
> > hate to say it, but we often scribble in /dev before
> > devfs is mounted and if you look at root file systems
> > mounted on other systems you well often find a /dev/null
> > FILE that got created during the boot process from a >/dev/null
> > before devfs was mounted.
> >
> 
> But for this issue, we're not mounting devfs early enough.  We should fix
> that. Removing /dev/null from the boot process likely is never going to
> happen because we use it all over the place to discard output... There's
> ~200 instances of it in the boot rc scripts, so getting rid of it there
> would also be quite the effort, with the same question.
I would like to see some evidence for this actually occuring.

We mount devfs instance before root (yes), to get the device nodes
available, so we can specify device name for root mount from loader.
After mounting root we do a rearrangement to move devfs to /dev, which
is somewhat tricky due to e.g. namecache.

I do not see how could anything in userspace even touch the underlying
directory on rootfs of the /dev devfs mount.

OTOH, it is a usual problem with /tmp getting dirty, and the garbage
hidden with tmpfs/md UFS mount over /tmp.