From owner-freebsd-current@FreeBSD.ORG Wed May 28 01:37:02 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 034D337B401 for ; Wed, 28 May 2003 01:37:02 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 9C1E643F75 for ; Wed, 28 May 2003 01:37:00 -0700 (PDT) (envelope-from mdcki@gmx.net) Received: (qmail 32260 invoked by uid 65534); 28 May 2003 08:36:58 -0000 Received: from pD9E2D193.dip.t-dialin.net (EHLO gmx.net) (217.226.209.147) by mail.gmx.net (mp011) with SMTP; 28 May 2003 10:36:58 +0200 Message-ID: <3ED4756C.4090402@gmx.net> Date: Wed, 28 May 2003 10:38:04 +0200 From: Marcin Dalecki User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030517 X-Accept-Language: en-us, en, pl, ru MIME-Version: 1.0 To: Scott Long References: <200305281147.53271.doconnor@gsoft.com.au> <1054090968.1429.10.camel@boxster> <3ED4294B.4040108@btc.adaptec.com> <1054092793.1429.39.camel@boxster> <3ED4315F.8080709@btc.adaptec.com> In-Reply-To: <3ED4315F.8080709@btc.adaptec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Q 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 08:37:02 -0000 Scott Long wrote: > Q wrote: > >> Don't overreact. > > > Heh. I live this hell every day with Linux in my day job. > >> I'm not suggesting taking the linux approach of >> versioning every module. But rather allowing the loader or a module >> (most likely a 3rd part or from a port) the ability to make a decision >> based on some internal revision/date based "version" as to whether it is >> safe to proceed to load. > > > Ideally, every API would be versioned, and developers would be careful > to architect their work so that the interfaces would be stable and > gratuitous incompatibilities would be avoided. Alas, that is not always > the case. > NO no and again no. This would repeat the same design mistake that is already in Linux. On API level you DO NOT WANT versioning. What you really want is: type signature cheking. Like for example done through C++ symbol mangling rules. If you can't do it like that then better leave it off as it is. Versioning in itself helps literally nothing and introduces many many problems in esp. if you are using a "vendor supplied" kernel and are trying to deploy add on modules - which is about the only point in time where you need to care about versioning.