Jon Maloy, el  4 de octubre a las 11:08 me escribiste:
quoted text
> Hi Peter,
> Adding the version as a sockopt is a very is a very good idea. 
> But actually, you can find out the version, and get around the two-binary problem aready now:
> 
> Check if TIPC_SUB_SERVICE is zero. If it is, the version is 2.0,
> otherwise it is pre-2.0, and you should use the TIPC_SUB_SERVICE with
> a value of 1.
> A little hackish, maybe, but it would solve your problem (which is
> temporary anyway) provided you can alter and recompile your code. 
> 
> And, since you are anyway altering the code, you should take the
> opportunity to add the necessary byte-order conversions, since
> TIPC-1.6/7 are forward compatible in that respect.
> 
> The only reason to introduce what Luca is suggesting, compatiblity
> code in the driver itself, is that you wouldn't need recompile your
> old apps.
> lf that is an absolute requirement we could do that, but our initial
> assessment was that most people recompile their code when moving to
> a new kernel. We may be wrong there, of course.

I thought the kernel usually went to great lengths to ensure old
userspace binaries work with newer kernels.

Since this, as you mention, is not hard to do, and does not impose
a penalty on new code, why not do it?

quoted text
> It is also uncertain whether David M would accept such a change, or if
> he would see it as a way of sneaking back a functionality he already
> threw out.

By the way, this doesn't work at all for the "bindings" I've done to the
D programming language. D is ABI compatible with C, but not source
compatible, so to add TIPC support to D, I had to write all the constant
values again, in a D source file[1].

This means D can't be used to write code that uses TIPC if you target
kernels >= 2.6.35 (unless they write their own bindings, or at least use
a custom TIPC_SUB_SERVICE constant). I could change the TIPC_SUB_SERVICE
value, but then people using older kernels will be screwed. Another
option is to use the version statement (kind of like C's #ifdef):

	version (TIPC_2_0)
		const TIPC_SUB_SERVICE = 0x00;
	else
		const TIPC_SUB_SERVICE = 0x02;

But then, *users* (I mean *end-users* not developers) will need to use
a compiler switch to select for which kernel they would like to compile
their applications, which I find unacceptable.

I think is really very harsh too to force people to recompile their
applications if they want to switch to a newer/older kernel to try
something out.

What I expected is to have something like 2 port names assigned to the
topology services instead of one, TIPC_TOP_SRV which is compatible with
TIPC 1 and marked as deprecated, and TIPC_TOP_SRV2 which only accepts
the TIPC 2.0 standard. Then, nothing of this would have happened.

And I think breaking changes should be discussed (or at least announced)
in this list more thoughtfully before including them in a Linux kernel
release. Is really a shame to be at a point where no matter what is
done, at least a couple of kernel releases will be binary incompatible
with old TIPC applications.


[1] http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/c/linux/tipc.d

PS: Since this is David Miller's call, I'm Cc-ing him (and other kernel
    mailing lists), as it makes no sense to speculate about what he
    thinks if we can just ask him.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
I'll take a quiet life,
a handshake of carbon monoxide,
with no alarms and no surprises,
no alarms and no surprises.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/