From owner-cvs-all Tue Dec 29 23:10:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA12439 for cvs-all-outgoing; Tue, 29 Dec 1998 23:10:24 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA12294; Tue, 29 Dec 1998 23:09:04 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (peter@localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Netplex) with ESMTP id PAA84781; Wed, 30 Dec 1998 15:07:44 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199812300707.PAA84781@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Darren Reed cc: phk@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: kvm_nlist emulation of n_type from kld symbol table at runtime. In-reply-to: Your message of "Wed, 30 Dec 1998 17:45:09 +1100." <199812300645.RAA16732@avalon.reed.wattle.id.au> Date: Wed, 30 Dec 1998 15:07:43 +0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Darren Reed wrote: > > If you're exporting symbols through something like a /dev/ksyms where > you can do "nm /dev/ksyms" and get a human-readable listing of the in-kernel > table, then n_type is essential (for obvious reasons). Yes, I thought about that a few times and I'm fairly convinced that doing a /dev/ksyms will be Really Hard (tm) and/or resource expensive given the way things are presently implemented. In a situation where there is a single loaded symbol table, this is easy. However, we have multiple symbol tables and in multiple formats. At present, I think the majority of cases have an a.out kernel symbol table and ELF module symbols. A coherent symbol table would have to be constructed, and that would take a large block of memory to do it in one chunk... Otherwise making lseek()/read() work across a (say) 4K staging buffer in kernel memory would be messy, especially when there is potential for loads/unloads inbetween reads of the device. I'm really not sure how to best get large synthetic blocks of data out to the user. I know sysctl(2) has enough trouble. Speaking of sysctl(), it's been suggested that I try and use it rather than a syscall interface. I'm a little concerned about the implications of that, but then again I don't understand the implementation that well. As I understand it, for looking up a kernel symbol ("msgbuf"), a symbolic name (kern.syms.msgbuf) would first be translated into a numeric OID via a sysctl syscall. Then, the numeric OID would be looked up, and presumably an opaque (to sysctl(2)) block would be returned for the caller to interpret. If this is the case, then we hit the symbol tables in one call to locate the symbol, and then later hit it again to get the value using the previous key. If there is significant time in between the two calls the address found previously could change. Of course, I could be underestimating sysctl(2)'s capabilities. I suppose there isn't much stopping a numeric OID lookup to start with, where the mib number was actually an address of the symbol name to be copyinstr()'ed. In this case too, it should be pretty simple to do address->name lookups. If the second case is closer to reality, then presumably we can use the sysctl() infrastructure to lock process memory while preparing a large writeout in order to dump the symbol table... To do anything like this I will need pointers and/or help. Poul-Henning? > Darren Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message