Re: policy on GPL'd drivers?

On Wed, 28 May 2003, 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.
>

Uhh... it is not true that versioning does not help anything at all.
i'm not sure what type signatures would help you with - knowing that
	foo(int, void *)
still has teh same siganture doesn't tell you anything about what must be
passed in as values what assumptions about call order with bar(void *)
exist or anything else.

> Symbol versioning is good to implement "multi-flavoured" single binary
> objects (glibc uses it this way) and *not* for interface cheking.
> Again my main point is versioning on the symbol level simply makes no sense and
> worsens the situation. It's the fundamentally wrong approach to the actual
> problem.  The fact that Linux does something like this is only showing that Alan
> Cox and Keith Owens didn't get it either and one shouldn't repeat the mistake.
>

uhhh... symbol versioning != library versioning and really, in case of
glibc is pretty useless, very few if any glibc 2.2 progarms woiuld
actually run on a 2.1 system, making it all pretty pointless

> No more no less.
>