In article <CAKrYomi=8oWz4=_yd4hwvwp6xuexzmq+g89rdvddp8+k-t-...@mail.gmail.com>, Ryota Ozaki <ozaki.ry...@gmail.com> wrote: >Hi, > >Data structures of network protocol control blocks (PCBs) >(struct inpcb, in6pcb and inpcb_hdr) are not organized well. >Users of the data structures have to handle them separately >and thus the code becomes duplicated and cluttered. > >The proposal restructures the data structures, which eliminates >duplicate and cluttered code and makes further changes easy. > >A typical cleanup by the change looks like this: > >- if (tp->t_inpcb) >- so = tp->t_inpcb->inp_socket; >-#ifdef INET6 >- else if (tp->t_in6pcb) >- so = tp->t_in6pcb->in6p_socket; >-#endif >+ so = tp->t_inpcb->inp_socket; > >Also some duplicated functions for IPv4 and IPv6 are integrated: >tcp6_notify, tcp6_quench, etc. > >The change consists of two parts. The first half of the series of >commits tries to integrate all the data structures into one structure >(struct inpcb). The commits cleans up ugly code like above. >However, because the structure includes both IPv4 and IPv6 stuff, >the data size for IPv4 increases by 40 bytes (from 248 to 288). > >The second half of the series of commits addresses the increasement >of the data size by separating the data structure again while keeping >the code simple. By the change, struct inpcb has only common data >and newly introduced data structures, struct in4pcb and struct in6pcb >inherited from struct inpcb, have dedicated data for each protocol. >Even after the separation, users don't need to recognize the separation >and just need to use some macros to access dedicated data. >For example, inp->inp_laddr, which represents the local IPv4 address, >is now accessed through in4p_laddr(inp). Using these macros adds >some code complexity, but this is a trade-off between data size and >code complexity. > >The diffs are here: >- https://www.netbsd.org/~ozaki-r/restructure-inpcb-1.patch >- https://www.netbsd.org/~ozaki-r/restructure-inpcb-2.patch > >Also, you can see individual commits at github: > https://github.com/ozaki-r/netbsd-src/commits/restructure-inpcb > > >We can adopt either of the whole changes or only changes of the first half. >Which should we choose? Smaller data size or simpler code? > >By the way, I think the changes should be committed (if permitted) >after branching netbsd-10. When will the netbsd-10 branch come? >If it doesn't come soon, is it ok to commit the changes before branching?
Thanks! I wanted to do this for a long time... I don't see why it should wait for the branch... Best, christos
