Subject: Re: /kern/kernel
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Gandhi woulda smacked you <email@example.com>
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.