[ On Sunday, December 9, 2001 at 00:24:55 (-0500), Andrew Brown wrote: ]
> Subject: Re: kernel install target (was: CVS commit: syssrc/sys/conf)
>
> how do you actually *know* what the running kernel is?  if you can
> come up with a 100% fool-proof, cross-platform, cross-architecture
> method, please share.  :)

You don't, but if you're installing new kernels on a system by putting
them into the root directory then it's a pretty damn good assumption
that you actually know something of what you're doing and that the last
kernel to be booted was in fact "/netbsd".  If that's not true then
hopefully you're also smart enough to modify the install target to
correct it.  I.e. let's not invent problems here that are irrelevant.

> all i'm trying to do here is improve the current method.  at least
> this way, you can't accidentally overwrite your netbsd/i386 kernel
> with a netbsd/evbarm kernel (provided you've set DESTDIR, which you
> really oughta do...in fact, your cross compilation script aid should
> do that for you).  that really sucks.  trust me.

Yes, improved procedures are ever more important in a cross-build
environment....

> >I would suggest something more along these lines:
> >
> >install-kernel-${MACHINE_NAME}:
> >	if [ ! -f /netbsd.old ] ; then mv /netbsd /netbsd.old; fi
> >	newkern=netbsd-$$(sh $S/conf/osrelease.sh)-$$(basename $$(pwd))-$$(date '+%Y%m%d%H%M')-$$(cat version); \
> >	echo "install -c -m 444 -o root -g wheel netbsd /$$newkern";	\
> >	install -c -m 444 -o root -g wheel netbsd /$$newkern;		\
> >	rm -f /netbsd;							\
> >	echo "ln /$$newkern /netbsd";					\
> >	ln /$$newkern /netbsd
> >
> >(that's the absolute minimum info I'd put in the filename, BTW!)
> 
> overkill.  way overkill.  imho, of course.

Having worked almost simultaneously on many different releases and even
different *BSDs on up to a dozen machines at a time I can assure you
that's the absolute minimum info necessary if you're mucking about with
kernels.  Common sense should tell you the same.  Measure twice, cut
once.  Sure some of that info is available inside the file, but without
making it part of the filename you risk collisions.

> also note that in your method, there exists a small quantum of time
> where /netbsd *does not exist*.  i think that's worse.  the current
> install target uses mv (which calls rename(2)) to make that window
> much smaller via an "atomic" operation.

You're dreaming about problems that simply don't exist.  The reason for
using the specific name "/netbsd.old" is precisely because that's the
next name most boot loaders will try if thye can't load "/netbsd".

In any case it's trivial to improve my original suggestion to also cover
your concern (even though doing so is truly overkill!):

install-kernel-${MACHINE_NAME}:
	@newkern=netbsd-$$(sh $S/conf/osrelease.sh)-$$(basename $$(pwd))-$$(date '+%Y%m%d%H%M')-$$(cat version); \
	echo "install -c -m 444 -o root -g wheel netbsd /$$newkern";	\
	install -c -m 444 -o root -g wheel netbsd /$$newkern;		\
	if [ ! -f /netbsd.old ] ; then ln /netbsd /netbsd.old; fi;	\
	echo "ln -f /$$newkern /netbsd";				\
	ln -f /$$newkern /netbsd

> of course, having a link to the kernel isn't as important as having
> all the tools that need to do kernel groveling know where (or how) to
> find it.

You're getting way off track.  We're not talking about those problems
here.  In any case the goal of having an install kernel that works in
the way I've described is to always end up with the booted kernel
normally being "/netbsd".  If you've had to boot /netbsd.old or
/netbsd.last then something's abnormal and not having all your normal
tools work in such a situation is not a problem (because you'll probably
have booted it to single user mode and you'll be re-booting with
"/netbsd" right away anyway, RIGHT? :-).

> sounds like you need to upgrade your sources.  those errors should not
> occur (at least in that form) with anything current.

From what I read in my kernel's Makefile they shouldn't happen with the
sources I have either.  That's with 2001/06/24 sources, FYI...

Next time I have a week of spare time all in a row I'll be rearranging
my source trees and merging up to -current again.....

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>