> > 	cp netbsd /netbsd.new		# ensure more than enough space on root
> > 	mv /netbsd /netbsd.old		# keep most recent good kernel around
> > 	mv /netbsd.new /netbsd		# nice, atomic operation.
> > 
> > I don't like using 'cp' to write to /netbsd because programs may have that
> > file open, and it's bad to simply overwrite the data out from under them.
> 
> What does the overwriting via cp do, vs mv, that would generate bad
> situations?

The main thing is that if your root disk is nearly full, you are warned about
it because the first copy fails, and you never touch the /netbsd file. If you
use cp, it starts trashing the existing kernel file immediately and then if
it runs out of space it stops and you're left with a corrupt /netbsd file.

Another thing which is more annoying than dangerous, is that lots of programs
(ps, dmesg, ...) expect /netbsd to be the running kernel, because they read
the file to know where in kernel memory they should look for things. I really
don't like this behavior, but fixing it requires extra work in order to
accomodate historical precedent (libkvm needs to work on crashed kernel core
dumps, and a proper interface that duplicates libkvm without poking around in
/netbsd would need to be written such that it stayed in sync with libkvm).

So: if a program has opened /netbsd to look at it, using cp will stomp the
data seen by that program and confuse the heck out of it. Using mv ensures
that once a program has opened /netbsd, it will see a coherent file until it
is done; the kernel does not actually 'rm' a file that has been opened, until
there are no more opens on the file. All processes that open /netbsd after
the mv will see the new version of the file, and so they will be happy also.

Thus with the mv method you avoid accidental confusion in programs that do
"kernel groveling".

Todd Whitesel
toddpw @ best.com