Date: Fri, 24 Jul 1998 16:59:19 -0700 From: Mike Smith <mike@smith.net.au> To: wjw@IAEhv.nl Cc: mike@smith.net.au (Mike Smith), dfr@nlsystems.com, hackers@FreeBSD.ORG Subject: Re: SYSCTL ....... Message-ID: <199807242359.QAA01020@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 25 Jul 1998 01:47:55 %2B0200." <199807242347.BAA23128@surf.IAE.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> => > => 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. You miss my point; when the LKM creates a sysctl node, the act of creating the node should increment the reference count on the LKM, so that the LKM can't be unloaded without first deregistering the node. The intent here is to make it impossible to remove an LKM while there are things that hold references to it (eg. the access method functions or pointers in the node). > => 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 DMI people have a name:number mapping scheme that works. The problem with numbers is that you have to assign them. If I want to create fifteen new nodes, I can't do that until the IANA gives me numbers for them. In the limited cases where numbers are useful (SNMP), use a translation table. But don't hamstring the kernel database by forcing it to keep track of both naming conventions. > => > 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 ..... In the Bad Old Days, every node had an assigned OID. These days, most of them have their OIDs assigned when the tree is assembled. Lookup by name is more flexible (I can create names on the fly) Think for a moment about the variant link stuff if you like; if you mandate numbers, you'd have to get a new number for every new link token. > => > 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. Hmm. If the tree is highly dynamic and long-lived, this may be problematic. -- \\ 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 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?199807242359.QAA01020>