Subject: ah...

From: Mike Shaver <[email-masked]>
Date: Fri, 30 May 1997 11:17:00 -0400 (EDT)

I think something's a bit wonky here.

  if ((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
    perror("nothingserv: socket");
    return -1;
  }
# ./bind-indy 2000
nothingserv: socket: Socket type not supported
#

Perhaps I'll try building a new kernel...

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>              Commando Developer - Whatever It Takes
#>                                                                     
#> "See, you not only have to be a good coder to create a system like
#>    Linux, you have to be a sneaky bastard too." - Linus Torvalds

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 30 May 1997 19:34:01 +0200 (MET DST)

> nothingserv: socket: Socket type not supported

Hurz...  Looks like you either you disabled TCI/IP networking or libc
and the kernel use different constants for the arguments of socket(2).

  Ralf

---

From: Mike Shaver <[email-masked]>
Date: Fri, 30 May 1997 13:43:30 -0400 (EDT)

> and the kernel use different constants for the arguments of socket(2).

I've added some more verbosity, and the constants are AF_INET=2,
SOCK_STREAM=2, IPPROTO_TCP=6.

TCP is correct, but SOCK_STREAM in my kernel headers is 1, SOCK_DGRAM being
2.  That'd explain the UDP thing, anyway.

Yup, my test program works if I force SOCK_STREAM to be 1.
I guess I'll try and find the bogosity in the headers, then.

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>            Chief System Architect and Herder of Bits                
#>                                                                     
#> "Yoda say, `Just slap a little public key crypto into it' does not  
#>      a secure system make." -- Marcus J. Ranum ([email-masked])

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 30 May 1997 20:04:37 +0200 (MET DST)

> 2.  That'd explain the UDP thing, anyway.

One of the fun things with SGI...  Long time ago checked two SGI machines
running different OS versions for reference.  In one of them the values
for SOCK_STREAM and SOCK_DGRAM are swapped compared to the other.  I wonder
why.  But anyway, at that time I choose to clone the constants from the
newer one.

> I guess I'll try and find the bogosity in the headers, then.

[...]

No, the kernel and the kernel use different values:
>From asm-mips/socket.h:
/* Types of sockets.  */
enum __socket_type
{
  SOCK_DGRAM = 1,               /* Connectionless, unreliable datagrams
                                   of fixed maximum length.  */
  SOCK_STREAM = 2,              /* Sequenced, reliable, connection-based
                                   byte streams.  */
  SOCK_RAW = 3,                 /* Raw protocol interface.  */
  SOCK_RDM = 4,                 /* Reliably-delivered messages.  */
  SOCK_SEQPACKET = 5,           /* Sequenced, reliable, connection-based,
                                   datagrams of fixed maximum length.  */
  SOCK_PACKET = 10,             /* linux specific way of getting packets at
                                   the dev level.  For writing rarp and
                                   other similar things on the user level.  */
};

Grrr...  I somewhen moved the definitions of these constants from the
generic header files to the machine specific header files and somehow
lost the appropriate change to the library.  I did change this with an
eye into the future (IRIX / ABI compatibility) so we wouldn't need some
stupid conversion routine.  Actually I wonder why I was able to use
bind, so I'll have to enquire my setup a bit closer.

Thanks anyway ...

  Ralf

---

From: "William J. Earl" <[email-masked]>
Date: Fri, 30 May 1997 13:03:53 -0700

> why.  But anyway, at that time I choose to clone the constants from the
...

      The change was for SVR4 compatibility.  The older numbering (STREAM==1,
DGRAM==2) was the BSD variation; the newer numbering is derived from the TPI
(Transport Provider Interface) constants.  RISC/os had the same thing, except
it supported both (-systype bsd43 for the BSD headers and libraries,
-systype svr4 for the SVR4 headers and libraries).  (The number conflict
was resolved in the system calls, depending on the type of the executable.)

---

From: Mike Shaver <[email-masked]>
Date: Fri, 30 May 1997 17:25:28 -0400 (EDT)

> why.  But anyway, at that time I choose to clone the constants from the

Solaris is the same way...it's probably an SVR thing.
(If you're going to use sockets, though, why not use the BSD values?)

> bind, so I'll have to enquire my setup a bit closer.

FWIW, I'd prefer to keep the Linux constants, well, constant.
I don't see a problem with doing value swapping in an ABI routine
later on, a la Linux/SPARC<->Solaris.

Mike

---

From: "William J. Earl" <[email-masked]>
Date: Fri, 30 May 1997 14:59:07 -0700

> (If you're going to use sockets, though, why not use the BSD values?)

    SVR4 has sockets, and they are source-compatible with the BSD
version, but the detailed values needed to match the TPI values for
SVR4 implementation reasons.  When we did the MIPS SVR4 ABI, one
compromise MIPS and SGI had to make with the other vendors, who used
real SVR4 with fake sockets on top of TPI, instead of providing
compatibility on top of a non-SVR4 kernel with real BSD sockets,
was to agree to the SVR4 values for these constants.

 > later on, a la Linux/SPARC<->Solaris.

      For these constants, at least, the value swapping is simple enough,
and, as you point out, is probably already done for Linux/SPARC.  IRIX 5 and
IRIX 6 binaries definitely require the SVR4-style values.

---

From: "David S. Miller" <[email-masked]>
Date: Fri, 30 May 1997 18:11:01 -0400

How can you tell if you have an IRIX binary which needs the old or new
socket constants?  Is it at the COFF/ELF file format boundary?