In some email I received from Mike Pelley, sie wrote:
> 
> The patch for pfil.c seems to have reversed the intention of Matthew's earlier patch (revision 1.7).  He changed the LIST's to TAILQ's to allow output filters to be processed in the opposite order to input filters (as mentioned in the history section of the pfil.9 man page).
> 
> I haven't tested it, but I think the following patch (against revision 1.11) will restore this behaviour.  If I have confused something, please correct me ;o)
> 
> Thanks!  Mike.
> 
> ---
> A man without a religon is like a fish without a bicycle.
> 
> 
> --- pfil.c.orig	Mon Feb 21 21:56:48 2000
> +++ pfil.c	Mon Feb 21 22:05:05 2000
> @@ -76,9 +76,9 @@
>  		pfil_init(ph);
>  
>  	if (flags & PFIL_IN)
> -		pfil_list_add(&ph->ph_in, func, flags);
> +		pfil_list_add(&ph->ph_in, func, PFIL_IN);
>  	if (flags & PFIL_OUT)
> -		pfil_list_add(&ph->ph_out, func, flags);
> +		pfil_list_add(&ph->ph_out, func, PFIL_OUT);
>  }

This is currently correct as it is - passing PFIL_IN/OUT means you
lose PFIL_WAITOK which can be important, if not others (ok, so there
aren't any _yet_ :-).

>  static void
> @@ -99,7 +99,10 @@
>  	 * insert the input list in reverse order of the output list
>  	 * so that the same path is followed in or out of the kernel.
>  	 */
> -	TAILQ_INSERT_TAIL(list, pfh, pfil_link);
> +	if (flags & PFIL_IN)
> +		TAILQ_INSERT_HEAD(list, pfh, pfil_link);
> +	else
> +		TAILQ_INSERT_TAIL(list, pfh, pfil_link);
>  }

Thanks,
Darren