Date: Sat, 25 Jul 1998 01:47:55 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAE.nl> To: mike@smith.net.au (Mike Smith) Cc: wjw@IAEhv.nl, dfr@nlsystems.com, hackers@FreeBSD.ORG Subject: Re: SYSCTL ....... Message-ID: <199807242347.BAA23128@surf.IAE.nl> In-Reply-To: <199807242307.QAA00758@dingo.cdrom.com> from Mike Smith at "Jul 24, 98 04:07:04 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
You ( Mike Smith ) write: => > => Last time I was daydreaming about sysctl, I thought that using SYSINIT => > => functions to build the tree would be a good idea. This would have the => > => benefit of trivially adding in sysctl variables in kernel modules loaded => > => using KLD since it runs SYSINITs in the loaded modules. To support => > => unloading modules, a method of automatically disconnecting variables => > => defined by the module is needed. => > => > 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. => => Correct. We should incorporate the simple structure reference counting => implementation that Terry published a little while back (Terry, why is => this not on your webpage?). => => When registering a node, it should be possible to supply an object => against which a reference will be taken. In the case of an LKM, the => module may not be unloaded without its reference count being zero. I would consider multiple attempts to create a node redundant, since only one node will be created. The first invalidation of a node disables the node, more request to that nature will be again redundant. => Save yourself some grief, and eliminate numeric OIDs. Why would you say that? if we want to doSNMP we'd need atleast a translation from namestrings to numberstrings. => > The numeric sequences are more/most important entry for the structure. => > This due to the idea have on SNMP-mib's. => => No, and very bad. Numeric OIDs should be supported for *legacy* nodes => only. At first I find this a little strange, Tell me more ..... => > Given the fact that one of the most common operators on a MIB-tree will be => > get_next, I'm considering adding a UP-relation as well. This will make it => > possible to get back to the one-higher node in the same tree. => => The ability to traverse, and also to best-guess restart a traversal => from a node that no longer exists, is critical. Hence my reason not to remove the node, but invalidate it. The data is no longer there, but the node is. --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?199807242347.BAA23128>