Date: Wed, 30 Dec 1998 18:23:56 +1100 (EST) From: Darren Reed <darrenr@reed.wattle.id.au> To: peter@netplex.com.au (Peter Wemm) Cc: phk@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: kvm_nlist emulation of n_type from kld symbol table at runtime. Message-ID: <199812300723.SAA16755@avalon.reed.wattle.id.au> In-Reply-To: <199812300707.PAA84781@spinner.netplex.com.au> from "Peter Wemm" at Dec 30, 98 03:07:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some email I received from Peter Wemm, sie wrote: > > 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. I don't think a /dev/ksyms needs to be "fast", but if implemented well could possibly be used with mmap(). > In a situation where there is a single loaded symbol table, this is easy. > However, we have multiple symbol tables and in multiple formats. Well, then you need to pick one which can be used as a superset of the two. I'd expect they're all storing the same sort of information so this shouldn't be too hard. > 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... I'm confused about what you're saying here, the need for n_type shouldn't go away because of a.out -> ELF. Solaris has a.out & ELF support and at least appears to still support nlist.h on both a.out and ELF binaries. > 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. Try creating a pseudo chracacter device, with a buffer and apply read(2) or mmap(2) where necessary. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812300723.SAA16755>