[openib-general] [RFC] IB address translation using ARP

[Grant Grundler]

On Fri, Oct 14, 2005 at 08:38:18AM -0700, Caitlin Bestler wrote:
> > That's not who SDP is going to work on Linux, though.  Where 
> > not into your crude hacks to let broken applications work 
> > with new technology business.  Applications will have to use 
> > SDP directly or via getaddrinfo and we will never put in a 
> > broken sockets switch.
> 
> I can't think of a better example of something that is truly
> brain dead than an application *written* to use Sockets Direct
> Protocol.

That wasn't hch's point. His point was the kernel would never make
SDP transperent to user space. But using LD_PRELOAD and libsdp.so,
SDP can be transperently used by the application.
It's the user's (ok, maybe sysadmin's) choice.

...
> So if you aren't preserving the sockets API what is
> the point in using the protocol?

Yes, the intent is to let the application to continue using sockets API.
But if sysadmin is asking for AF_INET or AF_INET6, then they want TCP/IP
*plus* netfilter and other features in the linux kernel. Not something else.
If the sysadmin decides they don't need netfilter/tcp, then they can
use LD_PRELOAD as noted above.


> > And can you _please_ stop all thise time to market and 
> > similar business crap?  That simply doesn't matter when 
> > designing something properly.
> 
> If we really were to play stop-the-world-while-I-redesign-it
> games then the resulting solution would not use sockets, TCP
> or even Linux.

Well, linux kernel doesn't play "stop-the-world-while-I-redesign-it".
The revolution happened (open source collaborative developement).
Linux kernel development is now an evolution.

Rule #1 for linux kernel develepment: "labor is free"
We *know* that's not true in commercial reality.  But kernel developement
just works that way because of it's origins and Linus likes it that way.
If someone wants something changed in the linux kernel, they can
develope/submit the changes themselves or pay someone to do the work.
In either case, Linus doesn't pay for it.

Seems like a sufficient number of smart people agree with him and play
the game the way he has defined it. The folks who do NOT like his game,
grab some version of the source tree and do what they like with it (as
long as they meet licensing requirements). That's ok too.


> Real solutions, from NICs through Operating
> Systems, recognize that their legacy is part of their strength
> as well as a nuisance.

Legacy is definitely a linux strength.

Open source does NOT ignore legacy applications:
1) Anyone can continue to update and run on the linux kernel version
   they have source code for if they don't want to (or can't) change
   the application or newer kernels break the ABI.
   Many people are still very happy using 2.4 linux kernels.

 [ Linux kernel has no ABI obligation to closed source apps given
   the availability of source code. That's what vendors like RH, SuSE,
   and their competitors are paid to provide - support for stable ABI. ]

2) kernel developers DO modify open source user programs to work
   with "updated" kernel interfaces if there is a clear advantage.
   scsitools and pciutils might be a good examples.
   X.org might be a more contemporary one.

3) kernel developers do NOT break an API/ABI just because it's tuesday
   and they had a bad burrito for lunch. They eat their own dogfood and
   don't want to have ABI "events" on their box once a week either.
   Some ABIs have been deprecated or intentionally broken to improve things.
   But that's not the norm.  We know it's not painless.

4) deprecated functionality is clearly marked and only removed after
   a reasonably long period (at least 12 months, usually 2-3 years).
   I know apps live longer than that.

I live in many worlds: "paid to provide stable ABI", "be good citizen,
make changes available upstream", and "upstream is cost effective for HP".

hth,
grant