Date: Thu, 31 Dec 1998 11:30:32 -0800 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: Mike Smith <mike@smith.net.au>, Poul-Henning Kamp <phk@critter.freebsd.dk>, committers@FreeBSD.ORG Subject: Re: kvm_nlist emulation of n_type from kld symbol table at runtime. Message-ID: <199812311930.LAA01128@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 30 Dec 1998 23:24:53 MST." <199812310624.XAA07777@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > It would be trivial to implement in a sysctl, and we can even do it > > > > as > > > > sysctl kern.nlist.val.avenrun > > > > sysctl kern.nlist.type.avenrun > > > > if you want to... > > > > > > What about 'loadable' drivers that may have multiple symbols for > > > multiple interfaces, ala network cards? > > > > > > kern.nlist.ed0.softc? > > > > Eugh. I think we're at cross purposes here. Exporting the kernel > > symbol table for debugging purposes is one thing, exporting entities > > out of the kernel for eg. statistical operations is another entirely. > > What about for things such as interrupt counts, collisions, and such. > These aren't debugging issues, but do exist on a per-card basis. They're already available via a sysctl, currently using a privately-managed growable tree. There's no reason not to continue to do it this way. As I said, information of a parametric or statistical nature matches sysctl well. Debugging matches symbol table access well. The two are complementary, not exclusive. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199812311930.LAA01128>