From owner-freebsd-hackers Fri Jul 24 06:31:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA05931 for freebsd-hackers-outgoing; Fri, 24 Jul 1998 06:31:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fledge.watson.org (root@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA05910 for ; Fri, 24 Jul 1998 06:31:12 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id JAA22780; Fri, 24 Jul 1998 09:30:15 -0400 (EDT) Date: Fri, 24 Jul 1998 09:30:14 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: wjw@IAEhv.nl cc: Doug Rabson , hackers@FreeBSD.ORG Subject: Re: SYSCTL ....... In-Reply-To: <199807241032.MAA19151@surf.IAE.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 24 Jul 1998, Willem Jan Withagen wrote: > You ( Doug Rabson ) write: > => > Intresting point. > => > I haven't thought about this point. I considered that once submitted OID's > => > are there for ever. But evaporating LKM's would case some access trouble. > => > => I think that coping well with loading/unloading modules is a requirement > => since supporting loadable drivers (and other components) is a goal we > => should be working towards. > > It could have some influence on the data-structures if deleteing nodes is > a frequent operation. The alternative would be to invalidate te content > pointers. > It also puts a serious commitment by the LKM-builder. He needs to make shure > he unregisters everything he has registered. Which could be more than he/she > bargained for. 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. However, the interface should make it extremely easy for the lkm writer to register/unregister without excessive overhead. Also, to detect duplicate registrations, etc. 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 :). Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message