From owner-freebsd-current@FreeBSD.ORG Wed May 28 10:58:16 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 A17E537B40A for ; Wed, 28 May 2003 10:58:16 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id A493743FA3 for ; Wed, 28 May 2003 10:58:15 -0700 (PDT) (envelope-from leimy2k@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h4SHwEIF014101 for ; Wed, 28 May 2003 10:58:15 -0700 (PDT) Received: from mac.com (mac6.mpi-softtech.com [67.33.6.42]) (authenticated bits=0) by mac.com (Xserve/MantshX 2.0) with ESMTP id h4SHvlxl004867; Wed, 28 May 2003 10:57:48 -0700 (PDT) Date: Wed, 28 May 2003 12:57:54 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Paul Richards From: dave In-Reply-To: <1054141667.1792.5.camel@cf.freebsd-services.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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:58:17 -0000 >>> 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. > So the module dependency graph would have "nodes" that are either real or virtual modules. Virtual modules are provided by the kernel proper only which only uses them to satisfy a module dependency? Interesting [hope I got that correct :)] Sounds like a neat way to create a module framework, guide for 3rd party and commercial drivers to get support from FreeBSD itself. dave