Date: Wed, 28 May 2003 10:38:04 +0200 From: Marcin Dalecki <mdcki@gmx.net> To: Scott Long <scott_long@btc.adaptec.com> Cc: freebsd-current@freebsd.org Subject: Re: policy on GPL'd drivers? Message-ID: <3ED4756C.4090402@gmx.net> In-Reply-To: <3ED4315F.8080709@btc.adaptec.com> References: <C90CF9CA-9040-11D7-941E-0003937E39E0@mac.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ED4756C.4090402>