Date: Fri, 24 Jul 1998 18:31:31 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAE.nl> To: robert+freebsd@cyrus.watson.org Cc: wjw@IAEhv.nl, dfr@nlsystems.com, hackers@FreeBSD.ORG Subject: Re: SYSCTL ....... Message-ID: <199807241631.SAA28948@surf.IAE.nl> In-Reply-To: <Pine.BSF.3.96.980724092639.22685C-100000@fledge.watson.org> from Robert Watson at "Jul 24, 98 09:30:14 am"
next in thread | previous in thread | raw e-mail | index | archive | help
You ( Robert Watson ) write: => LKM writers should not register sysctl nodes unless they are willing to => delete them afterwards. It is the same as any kernel hook -- if an lkm => calls at_fork(), they are morally obligated to call rm_at_fork() when they => unload :). Otherwise things go down the tubes pretty quickly. I'm of the same position. And as such it'll be a 'good thing(tm)' if there is a way of deactivating the reference which goes with a MIB element. There are 2 possibilities: Deleting the whole oid. (What to do on the implicitly created intermediates) Deactivating the reference to which the OID-value pointed. If you chose for the last one, you'll always have "prove" of the fact that the LKM was at any loaded. => However, the interface should make it extremely easy for the lkm writer to => register/unregister without excessive overhead. Also, to detect duplicate => registrations, etc. Dupliacte registrations will/should lead to the same element to be created again. (perhaps with a different value) => I don not think deleting would be a frequent (read: performance-intensive) => activity, as relinking stuff in your running kernel is bound to be slow => anyway. Unless we plan to providing routing information or something => through a dynamic sysctl mechanism :). The solution for this is to be able to hand of part of the tree virtually to a routine which can generate the requested information. So your router-module should have a/more function(s) which allow it to extend the tree once this proc-node is hit. This tree can then be constructed or the answers could be returned on the fly by the current data. So currently I have a routine which does a recursive dump of the whole sysctl_tree which has the following heading: sysctl_dumptree( sysctl *node, oidfullname prefix ) To be able to dump your router table, you need to create a "proc-stub" in the sysctl tree which points to a set/list of routines, and if the dumptree routine is available, it is called to treedump what ever could be hidden behind the given prefix. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807241631.SAA28948>