From owner-freebsd-current@FreeBSD.ORG Thu Jun 5 08:07:26 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 1A6A937B401; Thu, 5 Jun 2003 08:07:26 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id D621243F75; Thu, 5 Jun 2003 08:06:54 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.6) with ESMTP id h55F6Pib036096; Thu, 5 Jun 2003 16:06:25 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h55F6GdI082377; Thu, 5 Jun 2003 16:06:24 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Paul Richards In-Reply-To: <20030605145111.GF76193@survey.codeburst.net> References: <26877.1054676171@critter.freebsd.dk> <20030603.160943.102571653.imp@bsdimp.com> <1054594801.1641.49.camel@cf.freebsd-services.com> <200306041001.07145.dfr@nlsystems.com> <20030604122445.GB68108@survey.codeburst.net> <1054730025.32554.15.camel@builder02.qubesoft.com> <20030604131628.GE68108@survey.codeburst.net> <1054734198.32568.23.camel@builder02.qubesoft.com> <20030605145111.GF76193@survey.codeburst.net> Content-Type: text/plain Organization: Message-Id: <1054825575.32554.28.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 05 Jun 2003 16:06:16 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: dfr@freebsd.org cc: phk@phk.freebsd.dk cc: "M. Warner Losh" cc: current@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: Thu, 05 Jun 2003 15:07:26 -0000 On Thu, 2003-06-05 at 15:51, Paul Richards wrote: > On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote: > > On Wed, 2003-06-04 at 14:16, Paul Richards wrote: > > > On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote: > > > > > > > Interfaces actually can be added at runtime. Existing objects (i.e. > > > > objects instantiated before the new interface was added) will continue > > > > to work as before. If methods from the new interface are called on old > > > > objects, the default method will be called. > > > > > > How can you add an interface at runtime? > > > > By loading a kernel module. If I load e.g. the agp kernel module, I add > > the agp_if interface to the kernel. > > Yes, I know that you can load a pre-compiled interface at runtime > and thereby add that interface, but you can only "create" interfaces > at build time because each method in the interface is uniquely > identified by a kobjop_desc struct, which is what I was referring to. What has build time got to do with anything? At build time, you have no idea what interfaces are available either. Besides modules can be built at a different time from the rest of the kernel. > > > The code which is doing the method dispatch has no real idea what > > methods (or what interfaces for that matter) that the object's class > > implements. You can't use the classes method table layout for the ops > > table since the caller has no way of knowing that layout (and the layout > > will be different for almost every class in the system). > > > > One possible way of making this slightly simpler might be to make the > > class point at a table indexed by interface ID, each entry of which is a > > table indexed by a method ID from that interface. This sounds fine in > > theory but in practice, it would end up slower due to the two memory > > accesses. > > That's along the lines of what I suggested at the start of the thread :-) Its still slower and wastes more memory and bloats the code for every call site. I have a better approach in mind which I will be trying out soonish.