From owner-freebsd-current@FreeBSD.ORG Tue Jun 3 08:51:59 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C13E37B401; Tue, 3 Jun 2003 08:51:59 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2ECC43FBD; Tue, 3 Jun 2003 08:51:58 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id BFC641B212; Tue, 3 Jun 2003 16:51:57 +0100 (BST) Date: Tue, 3 Jun 2003 16:51:57 +0100 From: Paul Richards To: "M. Warner Losh" Message-ID: <20030603155157.GH35187@survey.codeburst.net> References: <3EDB6A6F.827B7C22@mindspring.com> <20030602160411.GA24490@perrin.int.nxad.com> <20030603134717.GD35187@survey.codeburst.net> <20030603.085659.13314075.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030603.085659.13314075.imp@bsdimp.com> User-Agent: Mutt/1.5.4i cc: hmp@freebsd.org cc: current@freebsd.org cc: des@freebsd.org Subject: Re: VFS: C99 sparse format for struct vfsops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 15:51:59 -0000 On Tue, Jun 03, 2003 at 08:56:59AM -0600, M. Warner Losh wrote: > In message: <20030603134717.GD35187@survey.codeburst.net> > Paul Richards writes: > : You should look at kobj, it's precisely this sort of dynamic > : dispatching that it was designed to support. > > Too bad it is a little slow and not MP safe in its implementation. Yes, but it has the right design philosophy for this sort of situation and should be researched as an example of how to solve these sorts of problems. I'm not sure the dispatch is slow enough to cause serious overhead in the context of the tasks being performed and it maybe could be improved a little. I'm not sure that kobj actually needs to be MP safe if the kobj struct is always embedded in a structure at a higher level i.e. a use of kobj in say the device driver code will not interact with it's use by say the linker code so the locking can be done on device driver or linker level structs. I think that's the case currently, though perhaps not something we've defined as part of the API, but there's no reason we could not do so and then that simplifies the use of kobj by avoiding having to add locks right at the very bottom of the structure tree where they wouldn't be needed. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician]