On Wed, Jul 17, 2002 at 01:11:03PM -0700, Bill Studenmund wrote:

 > Index: tcp_input.c
 > ===================================================================
 > RCS file: /cvsroot/syssrc/sys/netinet/tcp_input.c,v
 > retrieving revision 1.122.2.8
 > diff -u -r1.122.2.8 tcp_input.c
 > --- tcp_input.c	2002/06/20 03:48:54	1.122.2.8
 > +++ tcp_input.c	2002/07/17 20:11:55
 > @@ -3238,6 +3238,7 @@
 >  #endif
 >  	else
 >  		tp = NULL;
 > +	tp->t_flags = sototcpcb(oso)->t_flags & TF_NODELAY;
 >  	if (sc->sc_request_r_scale != 15) {
 >  		tp->requested_s_scale = sc->sc_requested_s_scale;
 >  		tp->request_r_scale = sc->sc_request_r_scale;

This patch looks okay to me.  I'd suggest checking it in, closing the
PR, and submitting a pullup for netbsd-1-6 branch.

 > I only copy over TF_NODELAY as it's the only user-settable tcp flag.

Yah, that seems reasonable.

 > I don't think we need to worry about this (in this particular case) as I
 > can't think of a case where a program would sett TCP_NODELAY on a
 > listening socket and expect it not to be set on the connected ones; BSD
 > wisdom was that you set TCP_NODELAY after the accept, and Linux wisdom
 > (one of the things I think Linux actually did right) is that you set
 > TCP_NODELAY on the listening socket so that you get it set on all of the
 > connected ones.

I agree with your analysis that it will not be a problem in practice.

 > I think the change should be documented, but I'm not sure where. It would
 > seem weird to discuss TCP_NODELAY on the accept(2) man page, but anywhere
 > else might be a bit burried.

Document it where TCP_NODELAY is documented (which should be the tcp(4)
manual page).

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>