On (08/21/08 17:30), Peter Memishian wrote:
> > 6737341
> <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6737341>
> tcp_host_param should be removed
>
> As per my comments in 6737341:
>
> I'm a bit confused here. Surely this interface had a purpose (and
As stated in cr 4337993
[EMAIL PROTECTED] 2000-07-16
I believe the intention is to not support TCP's host param table for IPv6 but
rather leverage the routing table, so it's unlikely this will be fixed.
Or, if you prefer, from CR 4497061,
[EMAIL PROTECTED] 2003-03-31
I agree with Kacheong, and I'd go further. This interface is just
plain awful and should be removed with extreme prejudice. The kernel
shouldn't be in the business of formatting and parsing strings, and
string-based interfaces make lousy programming interfaces.
If the feature is needed at all, a much more general mechanism is
required. I'd recommend having something that can set the
tunable-parameter entries in {{SOL_SOCKET,SO_*},{IPPROTO_IP,IP_*},
{IPPROTO_TCP,TCP_*},{IPPROTO_UDP,UDP_*},...} based on a configurable
match that's tested when bind() and connect() are done by the
application -- something that can match (at least) on IP address and
transport port numbers, and perhaps also application name and UID.
That would kill several birds with one stone -- you'd be able to tune
the send/receive space for various object-code-only applications, as
well as define simple but effective policies for IP_TOS without having
to touch every packet in IPQoS.
(As far as the ARC is concerned, this is an Unstable interface, which
means that you can yank it from a minor release, such as Solaris 10,
without bothering with the EOL process. ARC review and release notes
for S10, though, are required. I would try to add release notes for
an earlier release to warn customers about the problem, since we made
the mistake of documenting these tunables far and wide without warning
sufficiently that they're Unstable.)
So, given that the interface is pretty broken today, and certainly
does not belong in ndd, we're cleaning up the crud as part of Brussels 2.
> actually could be pressed into service if one knew its quirks).
It's not clear that it ever actually worked. Maybe Kacheong can provide
details.
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
