Date: Tue, 3 Jun 2003 16:51:57 +0100 From: Paul Richards <paul@freebsd-services.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: des@freebsd.org Subject: Re: VFS: C99 sparse format for struct vfsops Message-ID: <20030603155157.GH35187@survey.codeburst.net> In-Reply-To: <20030603.085659.13314075.imp@bsdimp.com> References: <3EDB6A6F.827B7C22@mindspring.com> <20030602160411.GA24490@perrin.int.nxad.com> <20030603134717.GD35187@survey.codeburst.net> <20030603.085659.13314075.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 03, 2003 at 08:56:59AM -0600, M. Warner Losh wrote: > In message: <20030603134717.GD35187@survey.codeburst.net> > Paul Richards <paul@freebsd-services.com> 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]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030603155157.GH35187>