From owner-freebsd-current Mon Mar 27 0:37: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 91DCF37BC60 for ; Mon, 27 Mar 2000 00:36:56 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 12ZV14-000Ho5-0W; Mon, 27 Mar 2000 09:36:55 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA06463; Mon, 27 Mar 2000 09:39:59 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 27 Mar 2000 09:43:38 +0100 (BST) From: Doug Rabson To: Andrzej Bialecki Cc: freebsd-current@freebsd.org Subject: Re: Dynamic sysctls - patches for review In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 26 Mar 2000, Andrzej Bialecki wrote: > On Sun, 26 Mar 2000, Doug Rabson wrote: > > > On Sun, 26 Mar 2000, Andrzej Bialecki wrote: > > > > Well, somehow the idea of overlapping subtrees sounds nice and useful > > > IMHO. Any suggestions how to solve these issues? > > > > > > One possible way to do it would be to keep some ID of the oid's > > > creator. Then, for nodes they would be deleted when the refcnt goes to 0 > > > (no matter who created them), but for terminals the deletion would succeed > > > only for the owners. Also, if you create a subtree not from the root of > > > dynamic tree, the refcnt++ would propagate up the tree as well, and > > > similarly refcnt-- would propagate on deletion. > > > > This is a reasonable solution. Another would be for dynamic sysctl users > > to use a 'context' object to record all their edits to the tree which > > would allow the edits to be backed out without relying on a tree-delete > > operation. > > Could you explain it further? Do you mean something like a transaction > log? But this wouldn't work - the operations on the tree can be > interdependent between users. I just mean creating an object to hold pointers to all the sysctl nodes and leaves which were created (or which had their refcounts incremented). To back out the module's edits, it would just run through the list and destroy each node/leaf. The destroy procedure would decrement the refcount and use that to decide when to free the memory. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message