[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-sctp
Subject:    Re: [Lksctp-developers] [RFC PATCH] [SCTP]: Support the new specification
From:       Vlad Yasevich <vladislav.yasevich () hp ! com>
Date:       2008-04-14 1:13:08
Message-ID: 4802AFA4.7070700 () hp ! com
[Download RAW message or body]

Ivan Skytte Jørgensen wrote:
> On Friday 11 April 2008 21:56:11 Vlad Yasevich wrote:
>> Ivan Skytte Jørgensen wrote:
>>> ---connect.c---
>>> int connectx(void) {
>>> 	return 13; /*old implementation*/
>>> }
>>>
>>> int connectx_draft14(void) {
>>> 	return 14; /*new implementation*/
>>> }
>>> ---sctp.h---
>>> #ifndef SCTP_DRAFT13_CONNECTX
>>> extern int connectx(void) asm ("connectx_draft14");
>>> #else
>>> extern int connectx(void);
>>> #endif
>> This also means that any application attempting to rebuild with with
>> the new library, but using an old API, will have to change.
>> I don't know if we can get away this.
> 
> We have to. the API is a live draft. The burden should not be one programs 
> that follow the latest draft.
> 
>> Also, who defines SCTP_DRAFT13_CONNECTX or SCTP_DRAFT14_CONNECTX, depending
>> on how ifdef is written?
> 
> The application programmer define that.

Sorry, but once we do that, we essentially introduce dead code since this requires
modifications by the programmer and they should just fix the code and pass in NULL.

> 
> If he wants to use the new API then he does nothing. This means that the line
> 	extern int connectx(void) asm ("connectx_draft14");
> will be used. The compiler will generate references to connectx_draft14. on 
> runtime connectx_draft14 will be called.
> 
> If a newly compiledprogram tries to run with an old lksctp then the program 
> cannot start at all due to missing symbol.
> 
> If the application programmer thinks it is too much of a burden to fix the 
> calls to sctp_connectx() then he can #define SCTP_DRAFT13_CONNECTX and the 
> line:
> 	extern int connectx(void);
> will be used. The compiler will generate references to connectx. on runtime 
> connectx will be called. If run with an old lksctp the program will function 
> fine.

Sorry, but I don't buy that.  If the programmer doesn't want to full power of
the new connectx(), he just pass in NULL as additional parameter and he done.
That's easier, IMHO, then to add a #define (less characters to type :>).

> 
> If a non-recompiled program uses the old API it will have references to 
> connectx, which is the old API.
>

That's the only part I am concerned about, but then your argument about the
api being a live draft also applies and once could put on onus on programmer again.

I think that we've accepted that we can not get away from breaking the API;
however, preserving the ABI is a worth goal and I look into that a bit more.
 
>> If we put that in netinet/sctp.h, then simply by recompiling against the
>> newer header, you have to change your program to comply to the new symbol
>> without ability to use the older one.
> 
> No. The programmer can define SCTP_DRAFT13_CONNECTX  if he wants to use the 
> old API.
> 
> 
> [snip]
>> I guess I have to figure out symbol versioning since I think anything
>> else falls short.
> 
> Symbol versioning does not solve the compile-time problem of old/new API.
> 

Neither does a #define.  It just works around it at the cost to the library providers.
I haven't been convinced that that cost is worth it.

-vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]