All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: linux-sctp@vger.kernel.org
Subject: Re: [Lksctp-developers] [RFC PATCH] [SCTP]: Support the new specification
Date: Mon, 14 Apr 2008 01:13:08 +0000	[thread overview]
Message-ID: <4802AFA4.7070700@hp.com> (raw)
In-Reply-To: <47F2AD4E.8000203@hp.com>

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

      parent reply	other threads:[~2008-04-14  1:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01 21:46 [Lksctp-developers] [RFC PATCH] [SCTP]: Support the new specification Vlad Yasevich
2008-04-01 22:42 ` [Lksctp-developers] [RFC PATCH] [SCTP]: Support the new specification of sctp Ivan Skytte Jørgensen
2008-04-02 15:50 ` [Lksctp-developers] [RFC PATCH] [SCTP]: Support the new specification Vlad Yasevich
2008-04-11 19:56 ` Vlad Yasevich
2008-04-12 11:11 ` [Lksctp-developers] [RFC PATCH] [SCTP]: Support the new specification of sctp_connectx() Ivan Skytte Jørgensen
2008-04-14  1:13 ` Vlad Yasevich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4802AFA4.7070700@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=linux-sctp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.