On Fri, 23 Jul 2010 12:44:38 +0100, Michael Brown wrote > On Friday 23 Jul 2010 06:59:56 Guo-Fu Tseng wrote: > > BTW, do you think it's reasonable to do something like: > > "[tcp] Cleanup TCP closing actions" patch which it sumbitted > > on gpxe-devel list?[2] > > > > I think it might be useful for following reasons: > > 1. We don't have to think of what would tcp_close() do if we call it > > somewhere. The behavior of calling tcp_close() would be always the same. > > 2. Reduced some duplicate code. > > 3. We don't have to separate tcp_close() from tcp_rx_fin(). And have the > > same behavior. Seems a little more neat to me. > > > > Above results are accomplished by: > > 1. Separate terminate action. > > 2. Separate terminate action. > > 3. Separate nullify xfer interface. > > (Which is part of "[tcp] Receive and Close flow adjustment"[1]) > > > > [1]: > > http://git.etherboot.org/?p=people/cooldavid/gpxe.git;a=commitdiff;h=8fc73d > > 18c8528cbcc1b1c3849b51d3ee3682c937 [2]: > > http://git.etherboot.org/?p=people/cooldavid/gpxe.git;a=commitdiff;h=660e96 > > 200f67c981e7397eb05fbb4e91ed253f50 > > Simplifying the closing actions would be good, though I'm not > immediately clear on what the patch would look like. How about > putting together a patch for > > [tcp] Deliver data only after updating TCP state > > i.e. the "struct list_head received ..." code I described, which > *doesn't* require tcp_xfer_shutdown() to be split out of tcp_close(), > and then adding the support for active/passive close and any cleanup > of closing actions on top of that? (It's up to you, but that's how I > would approach it.) > > Michael Sure, I can do this. :) I would like this approach too! Seems I misunderstood the "put together *A* patch". :p
Guo-Fu Tseng
