>> 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.

i'm not.  i'm fixing them.  by making the install target examine
DESTDIR, you can easily arrange for your kernels *not* to get
installed into your / at the drop of a finger.

>> 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.

your call, obviously.  we do different stuff.

>> 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".

whether that problem "exists" or not is irrelevant.  that sort of
thing was considered when kernel install target was originally set up
so that any *potential* problems could be avoided.

>> 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? :-).

no...this entire discussion is getting way off track.  there was an
install target in the kernel makefile, and has been for a while now.
i just made it better.  accidentally replacing my i386 kernel with a
evbarm kernel is, well, just plain aggravation.  it wasn't as if it
wasn't easy to fix (it was, because of how i organize my kernels), and
it wasn't as if it took all that much time (first a few seconds to
kick myself, then a few seconds of thought, and then a few more to
read /var/run/dmesg.boot to see which kernel i booted last) to fix.  i
don't even know why i typed make install.  certainly there are lots of
ways you can easily shoot yourself in the foot (i've even tried a few
on purpose), but making it harder to *accidentally* shoot yourself in
the foot is a "good thing".  making the kernel install target obey
DESTDIR is a "good thing".

>> 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.....

cool.  maybe then we can figure out what's wrong.  or maybe the
problem will just go away.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."