On Thu, Oct 19, 2000 at 09:35:20AM -0700, David S. Miller wrote:
> Date: Thu, 19 Oct 2000 18:30:22 +0200
> From: Andi Kleen <[EMAIL PROTECTED]>
>
> On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote:
> > I'll say it again, if you have to make changes to apps/servers the
> > feature does not make any sense. It must operate transparently or
> > not at all.
>
> Why? Linux historically required always some changes to port programs
> (e.g. UDP or accept error behaviour), one socket option more for some
> very special cases is not too bad.
>
> So you propose people should be required to port working programs
> between different Linux versions :-)
They already need probably, e.g. to handle the new UDP error behaviour.
Actually I did not propose to change the default behaviour (or rather
not change it back), just to give the applications a way to set the
behaviour *they* want as needed.
>
> > Therefore for the case you mention, for now they live without
> > non-local binds, period.
>
> The other guy unfortunately did not describe how exactly the java
> fails, so I cannot say what is worse.
>
> The JRE compliance tests have a test which makes sure that for a
> non-local addresses, bind() returns an error code, specifically
> -EADDRNOTAVAIL.
Sounds like a bug that should be reported to Sun.
>
> > Andi, listen to what you propose, LD_PRELOAD hacks to force programs
> > to set some magic socket option, and this is a real solution?
>
> LD_PRELOAD for binary only programs, patches for free software.
>
> User level binary compatability is everything, and why I have to
> revert this change in the first place.
I agree that the default should be 2.2 compatible. Adding the sysctl
to magically break these applications would be probably bad (just
remember ip_dynaddr and bind ;)
> Java isn't the only case, I have in fact seen code which tries to
> figure out whether XSHM pixmaps should be used by doing a bind() call
> using the X server's address.
Ok, sysctl to off (or better no sysctl and only the setsockopt to enable the
more liberal behaviour)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/