From owner-freebsd-current@FreeBSD.ORG Wed May 28 10:13:11 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 A519437B401 for ; Wed, 28 May 2003 10:13:11 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01D543F93 for ; Wed, 28 May 2003 10:13:10 -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 33AA71B216; Wed, 28 May 2003 18:13:09 +0100 (BST) From: Paul Richards To: dave In-Reply-To: <248EFE3A-912C-11D7-AD30-000393D6D7EE@mac.com> References: <248EFE3A-912C-11D7-AD30-000393D6D7EE@mac.com> Content-Type: text/plain Organization: Message-Id: <1054141667.1792.5.camel@cf.freebsd-services.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 28 May 2003 18:07:49 +0100 Content-Transfer-Encoding: 7bit cc: Q cc: Scott Long cc: freebsd-current@freebsd.org Subject: Re: policy on GPL'd drivers? 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, 28 May 2003 17:13:12 -0000 On Wed, 2003-05-28 at 17:48, dave wrote: > > > > I don't think anyone is talking about symbol versioning. The issue is > > stamping the API at a particular point in time that shows it behaves in > > a specified guaranteed way. > > > > The module system has all the hooks to deal with versioning. What's > > missing is not the mechanism but the knowledge, i.e. we don't know that > > module X won't work with kernel Y becuase we don't know what APIs > > module > > X may invoke and whether kernel Y supports them. > > > > > > > The only true solution to this is to version the APIs in the kernel and > > use the module versioning hooks to not load modules if the version > > isn't > > the right one. > > Will this require *any* new infrastructure to implement properly? Or is > it simply a matter of maintaining API metadata regarding versions. I think it'd just be a question of maintaining the metadata. There may be a little code missing but I don't think it would take a lot of work to complete the versioning mechanism. Creating all the metadata to actually define and version the APIs is another issue entirely though. Each module can maintain dependency data, stating which versions of other modules it can work with. The kernel would need to create virtual modules that held the faked module version for that API component. That wouldn't be very hard, just a linker set to record the API version in a module version structure. Ideally, whenever possible each API component should be grouped into a module anyway, but when that isn't possible just defining a faked module version should work. The kernel wouldn't then load a module if the kernel didn't support the APIs that the module depended upon. -- 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]