Date: Wed, 28 May 2003 17:35:56 +0100 From: Paul Richards <paul@freebsd-services.com> To: Marcin Dalecki <mdcki@gmx.net> Cc: freebsd-current@freebsd.org Subject: Re: policy on GPL'd drivers? Message-ID: <20030528163555.GJ6015@survey.codeburst.net> In-Reply-To: <3ED489A1.6090609@gmx.net> 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> <3ED4756C.4090402@gmx.net> <20030528104451.X12305@beagle.fokus.fraunhofer.de> <3ED489A1.6090609@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 28, 2003 at 12:04:17PM +0200, Marcin Dalecki wrote: > Harti Brandt wrote: > > >MD>NO no and again no. This would repeat the same design mistake > >MD>that is already in Linux. On API level you DO NOT WANT versioning. > >MD>What you really want is: type signature cheking. Like for example > >MD>done through C++ symbol mangling rules. If you can't do it like that > >MD>then better leave it off as it is. Versioning in itself > > > >Type signature checking doesn't help you if the semantics of an API change > >without type changes. APIs should be semantically and syntactically stable > >in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party > >driver for current is a nightmare, but may no be necessary once we have a > >-STABLE based on FreeBSD5. > > Sure sure. Perhaps I wasn't clear enough. Versioning doesn't help you > *anything* at all, but it is introducing new problems instead. Tons of them > in > fact, if one looks at the Linux pain in this area. I suggested type > signature > cheking in C++ style just to show how fundamentally flawed the idea of > version cheking is, but I can perfectly life with the situation as it is. > > Symbol versioning is good to implement "multi-flavoured" single binary 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. Some of the suggestions, such as using an MD5 hash, will prevent panics by refusing to load kernels that haven't been rebuilt since the kernel was, but it's a bit of a sledgehammer, since you don't want to have to rebuild all your modules every time you rebuild the kernel and in some cases (third party modules) you won't be able to, so such a mechanism won't work in practice. 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. -- 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]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030528163555.GJ6015>