From owner-freebsd-arch  Sat Sep  8 11:58:56 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by hub.freebsd.org (Postfix) with ESMTP id 20C0337B407
	for <arch@freebsd.org>; Sat,  8 Sep 2001 11:58:53 -0700 (PDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 8F1271E0E7; Sat,  8 Sep 2001 14:58:42 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA25707;
	Sat, 8 Sep 2001 14:58:24 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost)
	by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA12165;
	Sat, 8 Sep 2001 11:58:24 -0700 (PDT)
Message-Id: <200109081858.LAA12165@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: tlambert2@mindspring.com
Subject: Re: Causing <netinet/in.h> to depend on <sys/socket.h>
Cc: karels@bsdi.com, arch@freebsd.org
References:  <200109072125.OAA25298@windsor.research.att.com> <3B9A134D.3B31C443@mindspring.com>
Date: Sat, 8 Sep 2001 11:58:23 -0700
Versions: dmail (solaris) 2.2j/makemail 2.9b
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG


>So... we didn't need these before, why do we now?

uh... to introduce new functionality that we didn't have before?

We didn't need kernel threads before, why do we now?

>Why do they go in in.h?  Aren't they generic to all types of
>sockaddr's, not just sockaddr_in's?

The structures in question are part of an IP protocol independent
API for multicast group membership.  They use the struct sockaddr_storage
that was introduced by the IPv6 API to provide for forward compatability.
Since these structs are used as parameters to setsockopt(), it introduces
more complexity to pass pointers.

>I don't see anyone using the things.

I guess I'm missing what things you mean.  If you mean the new API that's
not in the system yet, that's because it's not in the system yet.  If you
mean sockaddr_storage, then you haven't looked particularly hard.

>Also: this is a DRAFT RFC... if it requires this type of thing,
>then it should probably be revised so that it _doesn't_ require
>this type of thing

The people who have already implemented the API (Microsoft is shipping it)
might not like that idea.

>I REALLY object to turning our header files into [polluting junk]

Well, how hard do you object to Mike's suggestion?  Especially since it's
POSIX-sanctioned pollution?

  Bill

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message