Date: Fri, 15 Dec 2006 11:53:00 -0800 From: Julian Elischer <julian@elischer.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: src-committers@FreeBSD.org, Andre Oppermann <andre@FreeBSD.org>, Luigi Rizzo <rizzo@icir.org>, cvs-all@FreeBSD.org, Randall Stewart <rrs@FreeBSD.org>, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/net Makefile.inc sctp_sys_calls.c src/sys/sys param.h Message-ID: <4582FD1C.9000501@elischer.org> In-Reply-To: <4582B395.3040501@FreeBSD.org> References: <200612151201.kBFC1qEv006825@repoman.freebsd.org> <4582A1E0.1050503@freebsd.org> <4582A6C9.8010009@FreeBSD.org> <20061215055704.A65183@xorpc.icir.org> <4582B395.3040501@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M. Simpson wrote:
> Luigi Rizzo wrote:
>>
>> i think Andre's question was this:
>> normally we use {set|get}sockopt() to configure the socket
>> as desired for special features (e.g. multicast is one).
>>
>>
> It already does. These are wrappers, not actual syscalls.
>> Why is it undesirable to use the same kind of overloading
>> for sctp ?
>
> An API is specified for SCTP already. Being forced to shoehorn all
> possible semantics into a getsockopt()/setsockopt() call *sucks* for
> serious work.
why? The API says it can be implemented via a set of library entry
points. How would you tell the difference?
>
> Regards,
> BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4582FD1C.9000501>