> Does some one have a copy of the posix 1003.1g draft so this can be
> verified. This is the kind of ammunition I was talking about earlier
1003.1g isnt what matters - SuS is.
> that I would need to convince Sun to change the compatibility test
> suite. However, if the 1003.1g draft even
Does some one have a copy of the posix 1003.1g draft so this can be
verified. This is the kind of ammunition I was talking about earlier
1003.1g isnt what matters - SuS is.
that I would need to convince Sun to change the compatibility test
suite. However, if the 1003.1g draft even
On Thu, Oct 19, 2000 at 12:30:52AM +0100, Alan Cox wrote:
> > Assuming that my "compatibility argument" is not considered valid. What
> > I really need is some good ammunition for going back to Sun to ask them
> > to change the JRE spec -- like some significant kernel features or Linux
> >
On Thu, Oct 19, 2000 at 12:30:52AM +0100, Alan Cox wrote:
Assuming that my "compatibility argument" is not considered valid. What
I really need is some good ammunition for going back to Sun to ask them
to change the JRE spec -- like some significant kernel features or Linux
applications
> [EMAIL PROTECTED] said:
> > There is NOT a bug in the JVM code that handles java.net.DatagramSock
> > et. Don't you find it a little compelling that the nearly identical
> > JVM code passes the Java Compatibility test suite on Linux 2.2,
> > Solaris, HPUX, SCO, and even Windows?
>
> If the
On Fri, 20 Oct 2000, Matt Peterson wrote:
> cvs-1.10.8/vms/rcmd.c:64:rs = bind(s, (struct sockaddr *)_isa,
^^^
> sizeof(local_isa));
> cvs-1.10.8/vms/rcmd.c:79:rs = bind(s, (struct sockaddr *)_isa,
^^^
> sizeof(local_isa));
>
> The cvs code does call bind,
Eric Lammerts wrote:
>
> On Fri, 20 Oct 2000, Matt Peterson wrote:
> > Are you also suggesting that every other program that expects bind() to
> > fail with EADDRNOTAVAIL are broken too? Just for fun, I greped all
> > sources of software shipped in Caldera's distributions for instances of
> >
On Fri, 20 Oct 2000, Matt Peterson wrote:
> Are you also suggesting that every other program that expects bind() to
> fail with EADDRNOTAVAIL are broken too? Just for fun, I greped all
> sources of software shipped in Caldera's distributions for instances of
> where a check is made for
[EMAIL PROTECTED] said:
> There is NOT a bug in the JVM code that handles java.net.DatagramSock
> et. Don't you find it a little compelling that the nearly identical
> JVM code passes the Java Compatibility test suite on Linux 2.2,
> Solaris, HPUX, SCO, and even Windows?
If the JVM spec
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > There is NOT a bug in the JVM code that handles java.net.DatagramSock
> > et. Don't you find it a little compelling that the nearly identical
> > JVM code passes the Java Compatibility test suite on Linux 2.2,
> > Solaris, HPUX, SCO, and
David Woodhouse wrote:
[EMAIL PROTECTED] said:
There is NOT a bug in the JVM code that handles java.net.DatagramSock
et. Don't you find it a little compelling that the nearly identical
JVM code passes the Java Compatibility test suite on Linux 2.2,
Solaris, HPUX, SCO, and even
[EMAIL PROTECTED] said:
There is NOT a bug in the JVM code that handles java.net.DatagramSock
et. Don't you find it a little compelling that the nearly identical
JVM code passes the Java Compatibility test suite on Linux 2.2,
Solaris, HPUX, SCO, and even Windows?
If the JVM spec says
On Fri, 20 Oct 2000, Matt Peterson wrote:
Are you also suggesting that every other program that expects bind() to
fail with EADDRNOTAVAIL are broken too? Just for fun, I greped all
sources of software shipped in Caldera's distributions for instances of
where a check is made for
Eric Lammerts wrote:
On Fri, 20 Oct 2000, Matt Peterson wrote:
Are you also suggesting that every other program that expects bind() to
fail with EADDRNOTAVAIL are broken too? Just for fun, I greped all
sources of software shipped in Caldera's distributions for instances of
where a
On Fri, 20 Oct 2000, Matt Peterson wrote:
cvs-1.10.8/vms/rcmd.c:64:rs = bind(s, (struct sockaddr *)local_isa,
^^^
sizeof(local_isa));
cvs-1.10.8/vms/rcmd.c:79:rs = bind(s, (struct sockaddr *)local_isa,
^^^
sizeof(local_isa));
The cvs code does call
[EMAIL PROTECTED] said:
There is NOT a bug in the JVM code that handles java.net.DatagramSock
et. Don't you find it a little compelling that the nearly identical
JVM code passes the Java Compatibility test suite on Linux 2.2,
Solaris, HPUX, SCO, and even Windows?
If the JVM spec
> Due ot this and other reasons I'm restoring the 2.2.x behavior by
> default, but adding a sysctl so that systems using dynamic addressing
> may elect to get the different bind() behavior.
>
> Later,
> David S. Miller
> [EMAIL PROTECTED]
If a system uses dynamic addressing, binding to
On Thu, Oct 19, 2000 at 10:45:02AM -0700, David S. Miller wrote:
> To this I agree, but I cannot change the fact that this assumption
> does exist in applications, so this is why I reverted the change.
Would you accept a patch for an setsockopt to enable it again ?
-Andi
-
To unsubscribe from
Date:Thu, 19 Oct 2000 11:35:12 -0600
From: Matt Peterson <[EMAIL PROTECTED]>
Don't you find it a little compelling that the nearly identical JVM
code passes the Java Compatibility test suite on Linux 2.2,
Solaris, HPUX, SCO, and even Windows?
He is arguing that returning
On Thu, Oct 19, 2000 at 11:35:12AM -0600, Matt Peterson wrote:
> Again, there is not a bug in the JVM's handling of
> java.net.DatagramSocket(). I offered the JVM as an example only because
> it is one application that I know of expects the standardized behavior
> of bind(). The bind() behavior
Andi Kleen wrote:
>
> > 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.
>
Hello? Send a bug to Sun? I don't see any logic here. I
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
"David S. Miller" <[EMAIL PROTECTED]> writes:
>Date: Thu, 19 Oct 2000 09:07:57 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Hence, the JVM fails compatibility on Linux 2.4.
>
> Due ot this and other reasons I'm restoring the 2.2.x behavior by
> default, but adding a sysctl so
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
In article <[EMAIL PROTECTED]> you wrote:
> Thus spake David S. Miller ([EMAIL PROTECTED]):
>> 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.
> There once was a socket file system which
Date:Thu, 19 Oct 2000 18:18:34 +0200
From: Felix von Leitner <[EMAIL PROTECTED]>
There once was a socket file system which solved exactly this
problem in a nice and obvious way. If you wanted to allow user joe
to bind to port 80, you just do "chown joe /socks/80".
I do
On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote:
>Date: Thu, 19 Oct 2000 17:56:17 +0200
>From: Andi Kleen <[EMAIL PROTECTED]>
>
>It would be better if there was at least an socket option to
>overwrite the sysctl. What happens when you need both behaviours on
>
Thus spake David S. Miller ([EMAIL PROTECTED]):
> 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.
There once was a socket file system which solved exactly this problem in
a nice and obvious way.
Date: Thu, 19 Oct 2000 17:56:17 +0200
From: Andi Kleen <[EMAIL PROTECTED]>
It would be better if there was at least an socket option to
overwrite the sysctl. What happens when you need both behaviours on
the same box in different applications ? (e.g. a dynamic IP box
running
On Thu, Oct 19, 2000 at 08:17:28AM -0700, David S. Miller wrote:
>Date: Thu, 19 Oct 2000 09:23:26 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Have you thought about an SOL_SOCKET level socket option? It might
>be more intuitive for programmers than an ioctl and could be
>
"David S. Miller" wrote:
>
>Date: Thu, 19 Oct 2000 09:23:26 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Have you thought about an SOL_SOCKET level socket option? It might
>be more intuitive for programmers than an ioctl and could be
>documented with sockets where it
Date: Thu, 19 Oct 2000 09:23:26 -0600
From: Matt Peterson <[EMAIL PROTECTED]>
Have you thought about an SOL_SOCKET level socket option? It might
be more intuitive for programmers than an ioctl and could be
documented with sockets where it will be used.
Where did I say "ioctl"?
"David S. Miller" wrote:
>
>Date: Thu, 19 Oct 2000 09:07:57 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Hence, the JVM fails compatibility on Linux 2.4.
>
> Due ot this and other reasons I'm restoring the 2.2.x behavior by
> default, but adding a sysctl so that systems using
Date: Thu, 19 Oct 2000 09:07:57 -0600
From: Matt Peterson <[EMAIL PROTECTED]>
Hence, the JVM fails compatibility on Linux 2.4.
Due ot this and other reasons I'm restoring the 2.2.x behavior by
default, but adding a sysctl so that systems using dynamic addressing
may elect to get the
"David S. Miller" wrote:
>
>Date:Wed, 18 Oct 2000 17:20:22 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Assuming that my "compatibility argument" is not considered valid.
>What I really need is some good ammunition for going back to Sun to
>ask them to change
Horst von Brand wrote:
> > > How about first finding out why their buggy JRE detects whether an
> > > address is local by trying to bind() to it :-)
>
> > I don't know why the JRE does it, but I've seen that sort of thing used
> > to decide whether to try X shared memory.
>
> Could you explain
[EMAIL PROTECTED] writes:
> Hello!
>
> > Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
> > address. The correct behavior should be a return code of -1 with errno
> > set to EADDRNOTAVAIL.
>
> You can bind to any address, it is your right. You will not able
> to
[EMAIL PROTECTED] writes:
Hello!
Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
address. The correct behavior should be a return code of -1 with errno
set to EADDRNOTAVAIL.
You can bind to any address, it is your right. You will not able
to receive on or
Horst von Brand wrote:
How about first finding out why their buggy JRE detects whether an
address is local by trying to bind() to it :-)
I don't know why the JRE does it, but I've seen that sort of thing used
to decide whether to try X shared memory.
Could you explain the logic
"David S. Miller" wrote:
Date:Wed, 18 Oct 2000 17:20:22 -0600
From: Matt Peterson [EMAIL PROTECTED]
Assuming that my "compatibility argument" is not considered valid.
What I really need is some good ammunition for going back to Sun to
ask them to change the JRE
Date: Thu, 19 Oct 2000 09:07:57 -0600
From: Matt Peterson [EMAIL PROTECTED]
Hence, the JVM fails compatibility on Linux 2.4.
Due ot this and other reasons I'm restoring the 2.2.x behavior by
default, but adding a sysctl so that systems using dynamic addressing
may elect to get the
"David S. Miller" wrote:
Date: Thu, 19 Oct 2000 09:07:57 -0600
From: Matt Peterson [EMAIL PROTECTED]
Hence, the JVM fails compatibility on Linux 2.4.
Due ot this and other reasons I'm restoring the 2.2.x behavior by
default, but adding a sysctl so that systems using dynamic
Date: Thu, 19 Oct 2000 09:23:26 -0600
From: Matt Peterson [EMAIL PROTECTED]
Have you thought about an SOL_SOCKET level socket option? It might
be more intuitive for programmers than an ioctl and could be
documented with sockets where it will be used.
Where did I say "ioctl"?
"David S. Miller" wrote:
Date: Thu, 19 Oct 2000 09:23:26 -0600
From: Matt Peterson [EMAIL PROTECTED]
Have you thought about an SOL_SOCKET level socket option? It might
be more intuitive for programmers than an ioctl and could be
documented with sockets where it will be
On Thu, Oct 19, 2000 at 08:17:28AM -0700, David S. Miller wrote:
Date: Thu, 19 Oct 2000 09:23:26 -0600
From: Matt Peterson [EMAIL PROTECTED]
Have you thought about an SOL_SOCKET level socket option? It might
be more intuitive for programmers than an ioctl and could be
Date: Thu, 19 Oct 2000 17:56:17 +0200
From: Andi Kleen [EMAIL PROTECTED]
It would be better if there was at least an socket option to
overwrite the sysctl. What happens when you need both behaviours on
the same box in different applications ? (e.g. a dynamic IP box
running
Thus spake David S. Miller ([EMAIL PROTECTED]):
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.
There once was a socket file system which solved exactly this problem in
a nice and obvious way.
On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote:
Date: Thu, 19 Oct 2000 17:56:17 +0200
From: Andi Kleen [EMAIL PROTECTED]
It would be better if there was at least an socket option to
overwrite the sysctl. What happens when you need both behaviours on
the same
Date:Thu, 19 Oct 2000 18:18:34 +0200
From: Felix von Leitner [EMAIL PROTECTED]
There once was a socket file system which solved exactly this
problem in a nice and obvious way. If you wanted to allow user joe
to bind to port 80, you just do "chown joe /socks/80".
I do not
In article [EMAIL PROTECTED] you wrote:
Thus spake David S. Miller ([EMAIL PROTECTED]):
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.
There once was a socket file system which solved exactly
"David S. Miller" [EMAIL PROTECTED] writes:
Date: Thu, 19 Oct 2000 09:07:57 -0600
From: Matt Peterson [EMAIL PROTECTED]
Hence, the JVM fails compatibility on Linux 2.4.
Due ot this and other reasons I'm restoring the 2.2.x behavior by
default, but adding a sysctl so that
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
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
Andi Kleen wrote:
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.
Hello? Send a bug to Sun? I don't see any logic here. I have
On Thu, Oct 19, 2000 at 11:35:12AM -0600, Matt Peterson wrote:
Again, there is not a bug in the JVM's handling of
java.net.DatagramSocket(). I offered the JVM as an example only because
it is one application that I know of expects the standardized behavior
of bind(). The bind() behavior in
Date:Thu, 19 Oct 2000 11:35:12 -0600
From: Matt Peterson [EMAIL PROTECTED]
Don't you find it a little compelling that the nearly identical JVM
code passes the Java Compatibility test suite on Linux 2.2,
Solaris, HPUX, SCO, and even Windows?
He is arguing that returning an
On Thu, Oct 19, 2000 at 10:45:02AM -0700, David S. Miller wrote:
To this I agree, but I cannot change the fact that this assumption
does exist in applications, so this is why I reverted the change.
Would you accept a patch for an setsockopt to enable it again ?
-Andi
-
To unsubscribe from
Due ot this and other reasons I'm restoring the 2.2.x behavior by
default, but adding a sysctl so that systems using dynamic addressing
may elect to get the different bind() behavior.
Later,
David S. Miller
[EMAIL PROTECTED]
If a system uses dynamic addressing, binding to an IP
Followup to: <[EMAIL PROTECTED]>
By author:"David S. Miller" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> How about first finding out why their buggy JRE detects whether an
> address is local by trying to bind() to it :-)
>
> Really, when an application feeds a specific address
Jamie Lokier <[EMAIL PROTECTED]> said:
> David S. Miller wrote:
> > How about first finding out why their buggy JRE detects whether an
> > address is local by trying to bind() to it :-)
> I don't know why the JRE does it, but I've seen that sort of thing used
> to decide whether to try X shared
> The XNS specification seems loose enough to allow the Linux
> behaviour. I don't
> think we should however adopt it as default behaviour. Programs
> that dont care
> about addresses use INADDR_ANY.
>
> Alan
I worry that an application may use ability to bind to determine whether an
David S. Miller wrote:
> How about first finding out why their buggy JRE detects whether an
> address is local by trying to bind() to it :-)
I don't know why the JRE does it, but I've seen that sort of thing used
to decide whether to try X shared memory.
-- Jamie
-
To unsubscribe from this
> Assuming that my "compatibility argument" is not considered valid. What
> I really need is some good ammunition for going back to Sun to ask them
> to change the JRE spec -- like some significant kernel features or Linux
> applications that relies on this new bind() behavior.
The XNS
Date:Wed, 18 Oct 2000 17:20:22 -0600
From: Matt Peterson <[EMAIL PROTECTED]>
Assuming that my "compatibility argument" is not considered valid.
What I really need is some good ammunition for going back to Sun to
ask them to change the JRE spec -- like some significant
On Wed, Oct 18, 2000 at 05:20:22PM -0600, Matt Peterson wrote:
> Your argument for supporting dynamic interfaces is valid, I really like
> the idea of being able to bind to an interface that is not up yet. I can
> definitely see where this would be helpful -- too bad is is not part of
> the spec.
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
> > address. The correct behavior should be a return code of -1 with errno
> > set to EADDRNOTAVAIL.
>
> You can bind to any address, it is your right. You will not able
> to
Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
address. The correct behavior should be a return code of -1 with errno
set to EADDRNOTAVAIL. (Simple snippet to reproduce/debug the problem is
available on request)
There appears to be significant differences between the
Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
address. The correct behavior should be a return code of -1 with errno
set to EADDRNOTAVAIL. (Simple snippet to reproduce/debug the problem is
available on request)
There appears to be significant differences between the
[EMAIL PROTECTED] wrote:
Hello!
Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
address. The correct behavior should be a return code of -1 with errno
set to EADDRNOTAVAIL.
You can bind to any address, it is your right. You will not able
to receive on or
On Wed, Oct 18, 2000 at 05:20:22PM -0600, Matt Peterson wrote:
Your argument for supporting dynamic interfaces is valid, I really like
the idea of being able to bind to an interface that is not up yet. I can
definitely see where this would be helpful -- too bad is is not part of
the spec.
Assuming that my "compatibility argument" is not considered valid. What
I really need is some good ammunition for going back to Sun to ask them
to change the JRE spec -- like some significant kernel features or Linux
applications that relies on this new bind() behavior.
The XNS
Date:Wed, 18 Oct 2000 17:20:22 -0600
From: Matt Peterson [EMAIL PROTECTED]
Assuming that my "compatibility argument" is not considered valid.
What I really need is some good ammunition for going back to Sun to
ask them to change the JRE spec -- like some significant kernel
David S. Miller wrote:
How about first finding out why their buggy JRE detects whether an
address is local by trying to bind() to it :-)
I don't know why the JRE does it, but I've seen that sort of thing used
to decide whether to try X shared memory.
-- Jamie
-
To unsubscribe from this list:
The XNS specification seems loose enough to allow the Linux
behaviour. I don't
think we should however adopt it as default behaviour. Programs
that dont care
about addresses use INADDR_ANY.
Alan
I worry that an application may use ability to bind to determine whether an
address
Jamie Lokier [EMAIL PROTECTED] said:
David S. Miller wrote:
How about first finding out why their buggy JRE detects whether an
address is local by trying to bind() to it :-)
I don't know why the JRE does it, but I've seen that sort of thing used
to decide whether to try X shared memory.
Followup to: [EMAIL PROTECTED]
By author:"David S. Miller" [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
How about first finding out why their buggy JRE detects whether an
address is local by trying to bind() to it :-)
Really, when an application feeds a specific address into
76 matches
Mail list logo
