report and comment

[Julian Elischer]

Julian Elischer wrote:
> I have MOSTLY merged the last commit into
> all the p4 branches..
> 
> progress should be good towards commit 1.5
> 
> 
> something I just noticed....
> 
> in sys/netinet/tcp_subr.c
> ================================================
> [...]
> #endif * Locking of the global variables isn_secret, isn_last_reseed, 
> isn_offset,
>  * isn_offset_old, and isn_ctx is performed using the TCP pcbinfo lock.  In
>  * general, this means holding an exclusive (write) lock.
>  */
> 
> #define ISN_BYTES_PER_SECOND 1048576
> #define ISN_STATIC_INCREMENT 4096
> #define ISN_RANDOM_INCREMENT (4096 - 1)
> 
> #ifndef VIMAGE
> static u_char isn_secret[32];
> static int isn_last_reseed;
> static u_int32_t isn_offset, isn_offset_old;
> static MD5_CTX isn_ctx;
> #endif
> 
> tcp_seq
> tcp_new_isn(struct tcpcb *tp)
> {
> [...]
> ================================================
> 
> and in sys/contrib/pf/net/pf_subr.c
> 
> ================================================
> [...]
>  * Locking of the global variables isn_secret, isn_last_reseed, isn_offset,
>  * isn_offset_old, and isn_ctx is performed using the TCP pcbinfo lock.  In
>  * general, this means holding an exclusive (write) lock.
>  */
> 
> #define ISN_BYTES_PER_SECOND 1048576
> #define ISN_STATIC_INCREMENT 4096
> #define ISN_RANDOM_INCREMENT (4096 - 1)
> 
> #ifndef VIMAGE
> static u_char isn_secret[32];
> static int isn_last_reseed;
> static u_int32_t isn_offset;
> static MD5_CTX isn_ctx;
> #endif
> 
> u_int32_t
> pf_new_isn(struct pf_state *s)
> {
> [...]
> =====================================================
> 
> so we have the same global variables, static, in 2 places..
> so one set should go in the pf vars and the other in the inet
> vars. The first answers I think of are:
> 
> 
> 1/ rename one set
> 2/ make one of them a VV_ macro that goes elsewhere.

looking at the code better... I see the entire function is about the 
same..

3/ remove the duplicated code in pf and call the one in tcp_subr.c
from both places..

> 
> anyone have other suggestions?
> 
> 
> 
> _______________________________________________
> freebsd-virtualization at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to 
> "freebsd-virtualization-unsubscribe at freebsd.org"