Date: Thu, 31 Dec 1998 10:13:46 +0800 From: Peter Wemm <peter@netplex.com.au> To: Mike Smith <mike@smith.net.au> Cc: committers@FreeBSD.ORG Subject: Re: kvm_nlist emulation of n_type from kld symbol table at runtime. Message-ID: <199812310213.KAA88685@spinner.netplex.com.au> In-Reply-To: Your message of "Tue, 29 Dec 1998 22:44:55 PST." <199812300644.WAA01817@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: > > Nutshell: Can anybody forsee the need to export symbol type to userland? > > > > Now for the details.. :-) > > > > The in-kernel linker keeps a small symbol table (of global symbols only for > > a stripped kernel). This is used for loading and unloading, to provide > > DDB with lookup capabilities, etc. > > > > Obviously, with a massively modular kernel (something we don't have yet, > > and hopefully we won't go overboard on), doing a kvm_mkdb(8) on /kernel at > > boot time and having kvm_nlist() read those is going to become rather > > useless rather quickly. > > > > The obvious solution is to provide access to the current symbol table to > > userland. > > No, the obvious solution is to improve and expand the sysctl interface, > which already provides size and type information. Type and size of the return, which in this case would be an opaque (to sysctl) block of data. The data needed to construct nlist.n_type is quite different to the data return type from sysctl(2). Nobody so far has commented on the need for nlist.n_type emulation.. Cheers, -Peter 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?199812310213.KAA88685>