Hi Thomas.

Thomas Klausner <wiz@netbsd.org> wrote:
> Hi Andrew!
> 
> > > If sysctl supports it, try to get the kernel name with CPU_BOOTED_KERNEL
> > 
> > o On certian architectures the PROM boot path is returned, *not* the Unix
> >   boot path. In this case, savecore will never work, because it won't fall
> >   back to _PATH_UNIX.
> 
> You have a point here. I'd think adding some code that tries to
> kvm_openfiles(3) the file returned by the sysctl (and falling back to
> _PATH_UNIX if that fails) would fix that problem.

You should at least ensure that the pathname is anchored, though (i.e. begins
with '/'), maybe even check it with secure_path().

> > o There are other utilities that depend on the name of the running kernel. 
> >   If we're `fixing' one to not expect _PATH_UNIX, we should fix them all:
> >   i.e., there should be a more dependable way to determine where the booted
> >   kernel is, and a call to get that information. FreeBSD has a getbootfile()
> >   function.
> 
> Grepping for _PATH_UNIX found me the following candidates:
> dist/ipf/ipsend/sock.c, gnu/dist/sendmail/sendmail/{conf.[ch],main.c},
> (lib/libkvm/kvm.c), libexec/identd/paths.h (but no c file there,
> weird), sbin/modload/modload.c, sys/dev/pci/ncrstat.c (what's that
> doing there?), usr.bin/ipcs/ipcs.c, usr.sbin/kgmon/kgmon.c,
> usr.sbin/kvm_mkdb/kvm_mkdb.c, usr.sbin/slstats/slstats.c,
> usr.sbin/syslog/syslogd.c, usr.sbin/trpt/trpt.c, usr.sbin/trsp/trsp.c.
 
> Not so big an undertaking that I wouldn't make a try at it; it's
> enough places that I understand your proposal of adding a
> getbootfile() call (to libutil, perhaps?). That should perhaps just

libutil would be the right place.

> try the sysctl and kvm_openfiles on the result, and if that fails,
> return _PATH_UNIX.

What you need to know is which ports actually know where the kernel is. If
it's worthwhile, it can be implemented, documented, and ports which don't
can get (if possible) brought up to speed. There's also netboot to at least
think about.

> > Please back this change out.
> 
> After adding some fallback code I think it would be better to have
> savecore behave slightly inconsistently with other tools, than let
> them all fail stupidly, and fix those other tools over time.
> 
> What do you think?

I'm more concerned about making savecore work on all architectures again.
I'd back the _PATH_UNIX part of the change out, ask for comment, and then
decide what to do.

> Feel free to forward this to some suitable mailing list.

Ok. Thanks.

Andrew