How do you address the problem of resolving addresses for crash dumps?
-Brian

On Sep 11, 12:03pm, Bill Studenmund wrote:
} Subject: Re: /kern/kernel
} On Thu, 10 Sep 1998, der Mouse wrote:
} 
} > Well, yeah.  My point is that for /kern/kernel to be useful, it has to
} > provide a symbol table for nlist() to use, and for that, it needs to
} > have the symbols available to it in the first place.
} 
} My thought is we should do something slightly different. Rather than try
} to point to the loaded kernel, why don't we just have something like
} /kern/kernelsymbols. It's a non-searchable directory, a la ~ftp/private.
} To look up a symbol, you just open /kern/kernelsymbols/the_symbol. If the
} symbol's defined, you'll get a file which, when read, is the kmem address
} of the symbol. If the sysmbol's not defined, you get a file not found
} error. If the support's not built in, you don't get a /kern/kernelsymbols
} directory.
} 
} This technique would work w/ net booted kernels, and a big advantage is
} with lkm's. If lkm's are loaded, we really should be exporting their
} symbols too. To do that w/ either the /netbsd route would be impossible I
} think. Just passing the address out sounds much easier than messing with
} faking an nlist which is then munged by a library in userland. 
} 
} If I understand things right, This in-kernel lookup wouldn't need many
} more resources than lkms as all the symbols and symbol lookup has to be
} there anyway.
} 
} This lookup could also be done through a sysctl.
} 
} Take care,
} 
} Bill
} 
>-- End of excerpt from Bill Studenmund