Re: git: 1922eb3e9c23 - main - protosw: retire pr_slowtimo and pr_fasttimo

From: Charlie Li <vishwin_at_freebsd.org>
Date: Sat, 20 Aug 2022 17:35:56 UTC
Gleb Smirnoff wrote:
> diff --git a/sys/sys/protosw.h b/sys/sys/protosw.h
> index 33f80a18cafd..6e46f40c8ad7 100644
> --- a/sys/sys/protosw.h
> +++ b/sys/sys/protosw.h
> @@ -52,8 +52,6 @@ struct sockopt;
>    * Each protocol has a handle initializing one of these structures,
>    * which is used for protocol-protocol and system-protocol communication.
>    *
> - * Thereafter it is called every 200ms through the pr_fasttimo entry and
> - * every 500ms through the pr_slowtimo for timer based actions.
>    * The system will call the pr_drain entry if it is low on space and
>    * this should throw away any non-critical data.
>    *
> @@ -67,8 +65,6 @@ struct uio;
>   
>   /* USE THESE FOR YOUR PROTOTYPES ! */
>   typedef int	pr_ctloutput_t(struct socket *, struct sockopt *);
> -typedef	void	pr_fasttimo_t(void);
> -typedef	void	pr_slowtimo_t(void);
>   typedef	void	pr_drain_t(void);
>   typedef void	pr_abort_t(struct socket *);
>   typedef int	pr_accept_t(struct socket *, struct sockaddr **);
> @@ -121,19 +117,12 @@ struct protosw {
>   /* protocol-protocol hooks */
>   	pr_ctloutput_t *pr_ctloutput;	/* control output (from above) */
>   /* utility hooks */
> -	pr_fasttimo_t *pr_fasttimo;	/* fast timeout (200ms) */
> -	pr_slowtimo_t *pr_slowtimo;	/* slow timeout (500ms) */
>   	pr_drain_t *pr_drain;		/* flush any excess space possible */
>   
>   	struct	pr_usrreqs *pr_usrreqs;	/* user-protocol hook */
> -	LIST_ENTRY(protosw)  pr_fasttimos;
> -	LIST_ENTRY(protosw)  pr_slowtimos;
>   };
>   /*#endif*/
>   
> -#define	PR_SLOWHZ	2		/* 2 slow timeouts per second */
> -#define	PR_FASTHZ	5		/* 5 fast timeouts per second */
> -
>   /*
>    * This number should be defined again within each protocol family to avoid
>    * confusion.
> 
> 
This broke net-mgmt/net-snmp, which uses PR_SLOWHZ directly. Upstream 
issue filed at https://github.com/net-snmp/net-snmp/issues/445

-- 
Charlie Li
…nope, still don't have an exit line.