From owner-freebsd-current@FreeBSD.ORG Wed Jun 4 05:35:31 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 9B69137B401; Wed, 4 Jun 2003 05:35:31 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2259243F75; Wed, 4 Jun 2003 05:35:30 -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 h54CXlib002752; Wed, 4 Jun 2003 13:33:47 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h54CXkdI051572; Wed, 4 Jun 2003 13:33:46 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Paul Richards In-Reply-To: <20030604122445.GB68108@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> Content-Type: text/plain Organization: Message-Id: <1054730025.32554.15.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 04 Jun 2003 13:33:46 +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: Wed, 04 Jun 2003 12:35:31 -0000 On Wed, 2003-06-04 at 13:24, Paul Richards wrote: > On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote: > > On Tuesday 03 June 2003 12:00 am, Paul Richards wrote: > > > On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote: > > > > In message: <1054590840.1641.12.camel@cf.freebsd-services.com> > > > > > > > > Paul Richards writes: > > > > : The possible methods available in an interface are fixed, they're > > > > : defined in the .m files. > > > > > > > > No it isn't. One can add additional interfaces at any time without > > > > breaking binary compatibility, so you don't know, a priori, the > > > > number of methods in a given interface when you build a client of > > > > that interface. > > > > > > I don't think that's true. > > > > > > The interface is defined in the .m file and it's created using > > > makeobjs. You can't do that at runtime because it creates the > > > kobj_desc struct that uniquely represents the existence of that > > > method globally for the whole of the kobj subsystem. The set of all > > > kobj_desc defines all possible methods that can be implemented by an > > > object, and yes you can extend that interface later and previously > > > built modules will still work because they only implement a subset of > > > those possible methods, but the set of all methods that can exist is > > > determined at compile time from the interface definitions > > > > > > A class is then defined which specifies the set of methods that > > > objects instantiated into that class *can* implement (but are note > > > required to). The set of methods in a class is also fixed, since it's > > > basically the method table plus some class fields and the method > > > table is created at compile time. Again though, if you later extend > > > the class older compiled modules will still work because if the > > > method doesn't exist in that older module the default from the > > > kobj_desc will be used or the kobj_error_method will be called (which > > > is safe). > > > > > > So yes you can extend the interface and the class and keep backwards > > > compatibility but that all happens at compile time, and therefore at > > > runtime when the object is instantiated you know the maximum number > > > of methods that the object can possibly call. > > > > It is true, I'm afraid. A class is can implement any number of > > interfaces so knowing the compile-time size of an interface doesn't > > help you reserve space for a class. The system is intended to have a > > robust ABI so that e.g. a class implementing an interface can be used > > safely by a kernel in which new methods have been added to that > > interface. > > I though Warner meant adding interfaces at runtime, but he meant > build time (I misread that). My comments about interfaces where > therefore in rebuttal of the possibility to extend them at runtime. > So yes, what Warner asserted is true but as I did also point out > above and you've confirmed below, it's the class that determines > the methods for an object and that is fixed when the object is > instantiated into that class. 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. > > > The class is a concrete definition of a set of methods (at this level, > > the interfaces are mostly ignored). Objects instantiated in that class > > use exactly that set of methods, no more, no less. There is no choice > > involved. You appear to be confusing class and interface here. > > Given that we agree that the method table is fixed at object > instantiation time, why isn't allocating a fixed array appropriate? Mainly because there isn't an easy way to decide how big the array should be. The older version of this code reserved enough space for all current interfaces. This ended up wasting a lot of space (per class, not per object) and still ended up with a table size comparison in the method dispatch since interfaces might get added after existing classes had been initialised.