Subject: Re: NetBSD-3 NIS-compat getpwnam()/getpwuid iterate entire map [was Re: 3.0 YP lookup latency]
To: Charles M. Hannum <mycroft@MIT.EDU>
From: None <jonathan@dsg.stanford.edu>
List: tech-net
Date: 06/22/2006 11:46:41
In message <20060622170553.GU11554@multics.mit.edu>"Charles M. Hannum" writes
>On Wed, Jun 21, 2006 at 03:36:53PM -0700, jonathan@dsg.stanford.edu wrote:
>> I am still very peturbed by the XXX comment. If someone like fvdl
>> doesn't grok why the setsockopt() is needed, we need a better
>> explanation. And I'm worried by both the dependency on the strncmp()
>> matching both "inet" and "inet6", when what's really meant is
>> "are we running over TCP"?
>
>FTR, I'm not really a fan of this use of strncmp().
FTR:, me too. At least four smart people read past my original
message, without comment, until you drow our attention to
the effect of
strncmp("inet6", "inet", 4);
>suggestion assumes there will never be an incompatible protocol named
>"TCP" in another protocol family. Is this a safe assumption? Who
>knows. I think it's better to test the protocol family *and* protocol
>if you're trying to be "careful".
Equally FTR, I checked yesterday that TUBA (TCP over CLNP) is long
dead in NetSBD and in other OSes which might borrow our code. I also
looked hard for TCP running over otehr protocols, and found only
defunct attempts to run TCP over raw ATM VCs.
Again, FTR, once I saw Christos' pointer to the second use
of TCP_NODELAY in rpc_vc.c, I reworked my own tree to use the
RPC-internal state.
Equally FTR, yesterday I was actively considering how to support
near-future of RPC over SCTP, where i beleive the conventional
API requires something like:
...
setsockopt(fd, IPPROTO_SCTP, SCTP_NODELAY, &one);
so I'd go further than Christos, and (modelled on Christos' code) pass
__rpc_setnodelay() a struct __rpci_sockinfo *si:
int
__rpc_setnodelay(int fd, const __rpc_sockinfo *si)
{
...
}
called as:
if (si.si_socktype == SOCK_STREAM)
__rpc_setnodelay(fd, &si);
That way, if we add SCTP support, we don't need to change any calls to
_rpc_setnodelay: updating the body of __rpc_setnodelay() will do. The
tests for consistency with current expectations (SOCK_STREAM RPC
implies TCP, which implies underlying IPv4/IPv6) that you (and I) both
want can be done inside __rpc_setnodelay().
Are we converging?