From owner-freebsd-current@FreeBSD.ORG Tue Jun 3 16:01:56 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 C64DB37B4F0; Tue, 3 Jun 2003 16:01:55 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76DF543F85; Tue, 3 Jun 2003 16:01:54 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: from [192.168.7.2] (freebsd.gotadsl.co.uk [81.6.249.198]) by mx0.freebsd-services.com (Postfix) with ESMTP id 01B671B212; Wed, 4 Jun 2003 00:01:53 +0100 (BST) From: Paul Richards To: "M. Warner Losh" In-Reply-To: <20030603.160943.102571653.imp@bsdimp.com> References: <26877.1054676171@critter.freebsd.dk> <1054590840.1641.12.camel@cf.freebsd-services.com> <20030603.160943.102571653.imp@bsdimp.com> Content-Type: text/plain Organization: Message-Id: <1054594801.1641.49.camel@cf.freebsd-services.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 00:00:02 +0100 Content-Transfer-Encoding: 7bit cc: phk@phk.freebsd.dk cc: dfr@freebsd.org 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: Tue, 03 Jun 2003 23:01:56 -0000 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. -- 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]