Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Jul 1998 09:30:14 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        wjw@IAEhv.nl
Cc:        Doug Rabson <dfr@nlsystems.com>, hackers@FreeBSD.ORG
Subject:   Re: SYSCTL .......
Message-ID:  <Pine.BSF.3.96.980724092639.22685C-100000@fledge.watson.org>
In-Reply-To: <199807241032.MAA19151@surf.IAE.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980724092639.22685C-100000>