cvs commit: src/sys/compat/linux linux_socket.c

[John Baldwin]

On Wednesday 09 March 2005 09:30 am, Maxim Sobolev wrote:
> Dag-Erling Smørgrav wrote:
> > Maxim Sobolev <sobomax at portaone.com> writes:
> >>As I have said the binary program compiled on the newer system that
> >>uses this flag in some cases may malfunction when executed on system
> >>with older kernel due to the fact that that additional flag will
> >>become no-op the program might get SIGPIPE unexpectedly.
> >
> > We've never cared about running newer binaries on older systems.  It's
> > the reverse that matters, and the change Alfred suggests does not
> > break that.
>
> Even if we've never cared about that it really matters and IMHO we need
> to start caring about that esp. considering that sendto(2) and friends
> are very popular syscalls. That's not a big problem if you have sources
> handy, but what if it's some third party tool which is only available in
> binary code?
>
> Imagine that we are talking about some very big and very popular toolkit
> such as for example JDK, which takes ages to go through all compliance
> testing and such. Once it's packed, tested and rubberstamped for
> distribution you have zero chance to convince vendor to release another
> version that will run on both new and older systems even if it will mean
> changing two or three lines of their code. The only thing the vendor can
> do is to put some warning "will work correctly only  starting from
> release X.Y", therefore forcing all users who run releases X.Z, Z < Y,
> and need this tool to upgrade otherwise perfectly working system(s).

And such vendors are encouraged to target, e.g. 5.3 for the 5.x series since 
that is the first "stable" release for that branch.  This is how we've always 
handled things.  Forwards compatibility is significantly harder to achieve 
than backwards compatibility.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org