Date: Sat, 8 Sep 2001 14:10:05 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Bill Fenner <fenner@research.att.com> Cc: tlambert2@mindspring.com, karels@bsdi.com, arch@FreeBSD.ORG Subject: Re: Causing <netinet/in.h> to depend on <sys/socket.h> Message-ID: <20010908141005.R20137@prism.flugsvamp.com> In-Reply-To: <200109081858.LAA12165@windsor.research.att.com> References: <200109072125.OAA25298@windsor.research.att.com> <3B9A134D.3B31C443@mindspring.com> <200109081858.LAA12165@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 08, 2001 at 11:58:23AM -0700, Bill Fenner wrote:
>
> >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.
It seems that the real problem here is that sockaddr_storage is supposed
to be protocol-neutral (used for appletalk, IPX, etc), but what your
code really wants is IP-specific sockaddr_storage.
Something like:
struct sockaddr_storage_in {
union {
struct sockaddr_in sin4;
struct sockaddr_in6 sin6;
} ssin;
};
This could be placed at the end of <netinet/in.h>, the way things
stand now. However, I'm not sure if this approach is better or worse
than just moving sockaddr_storage into <sys/sockettype.h>.
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010908141005.R20137>