On Mon, 11 Nov 1996, Curt Sampson wrote:

> On Mon, 11 Nov 1996, Bill Studenmund wrote:
> 
> > True, but you always have that problem. My experience (which might not
> > match everyone elses, I'll admit) is that I'm often hacking on the kernel
> > to do one thing or another. I don't often change the internal structures,
> > just where they live.
> 
> So long as you don't change the name of the structure, the kmem
> library will still find it. (It uses the namelist in the kernel.)
> So I'm not sure I understand what you're getting at here, unless
> you are talking about booting from a kernel other than /netbsd, in
> which case this is currently dealt with by the -N options, and
> could be made a bit easier by just symlinking /var/run/kernel to
> the booted kernel on boot, and having the kmem lib look at that by
> default.

The problem though is that many of these kernels only live long-enough for
the next bug to get identified or for another fix to be compiled. Having
to symlink each time is a hassle. Also, on boot, the savecore program goes
off looking for a kernel well before I have a chance to get the symlink
pointing in the right place. True, it never seems to do harm, but its
complaints about "can't find device 0/126" are anoying. The thing is the
computer CAN know better. :-(

> My proposal was indeed to have the information spit out in ASCII
> format. (Not that I'm actually all that keen on this proposal; I
> just don't see any other way around the problem right now.)

Hmm. If we do that big a change, I think we should have a different
program. The mac68k port used procps for quite a while in the early days.
I'd use it now if it'd give output like ps aux does. :-) Then it's a
user's choice to use the procfs/kernfs tools instead.

Take care,

Bill