Subject: Re: /kern/kernel
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Gandhi woulda smacked you <>
List: current-users
Date: 09/13/1998 22:25:00

Nice.  Sun uses the -i flag for this already; I think -r is reserved
under Slowlaris, but that's moot :-).  Good ideas!

Working on a dead kernel is easy since you specify the kernel
with which to debug; stabs are already in the binary.

Working in the live universe, as I just suggested (so this message
may overlap) would be easy; have the kernel reference its own
symbol table into core and have a userland process tell the system
to dump its stab into a file and flush it from core once it goes
multi-user.  Meanwhile, until it's saved and flushed, it's in core
and easily accessible.

This would require system calls to support it, or augmentation
of existing calls.

No, I'm not volunteering -- I'm still having problems writing
a driver for my antares 4-port board ('cos I don't know how to reference
a "ATMI,20-050-0014" yet).

On Sun, 13 Sep 1998, der Mouse wrote:

 * > Maybe a more drastic solution is in order: add a boot option that
 * > chroot's to a directory before loading /netbsd and the booted kernel
 * > uses that directory as root.
 * You don't need the former, since you can specify (eg) /current/netbsd
 * as the kernel-to-load.
 * I just hacked in support for booting with -r, which prompts for a root
 * directory to run under at boot time.  It passes a smoke test, but needs
 * real testing.  (I'm also going to add -i, to make it prompt for a path
 * to use for init, instead of just hardwiring three paths.  As it stands,
 * if you install an init binary that's execable but broken, you have to
 * boot from alternative media to recover.)  Anyone care to offer opinions
 * on whether these approaches are good or bad?
 * 					der Mouse
 * 		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Friends don't let friends use Microsoft.