From owner-freebsd-hackers  Fri May 30 09:37:02 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA24047
          for hackers-outgoing; Fri, 30 May 1997 09:37:02 -0700 (PDT)
Received: from pdx1.world.net (pdx1.world.net [192.243.32.18])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24042
          for <hackers@freebsd.org>; Fri, 30 May 1997 09:36:59 -0700 (PDT)
From: proff@suburbia.net
Received: from suburbia.net (suburbia.net [198.142.2.24]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id JAA25481 for <hackers@freebsd.org>; Fri, 30 May 1997 09:40:03 -0700 (PDT)
Received: (qmail 5042 invoked by uid 110); 30 May 1997 16:36:38 -0000
Message-ID: <19970530163638.5041.qmail@suburbia.net>
Subject: Re: IPFILTER kernel woes (FreeBSD 3.0-current)
In-Reply-To: <199705301607.SAA19122@gil.physik.rwth-aachen.de> from Christoph Kukulies at "May 30, 97 06:07:37 pm"
To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies)
Date: Sat, 31 May 1997 02:36:37 +1000 (EST)
Cc: ipfilter@postbox.anu.edu.au
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> I'm biting through and having got around one hurdle another one piles up:
> 
> My kernel options is IPFILTER (not IPFILTER_LKM - maybe that's
> making things more weird). Anyone I wonder if anyone has gotten
> through compiling a FreeBSD-3.0 of today IPFILTER kernel yet.
> 
> This is what I'm getting now:
> 
> cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit  -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes  -Wpointer-arith  -nostdinc -I- -I. -I../.. -I../../../include -DGUSMAX -DDEVFS -DIPFILTER_LOG -DIPFILTER -DIPDIVERT -DUSER_CONFIG -DCOMPAT_43 -DMSDOSFS -DMFS -DNFS -DFFS -DINET -DKERNEL -include opt_global.h  ../../netinet/mln_ipl.c
> ../../netinet/mln_ipl.c: In function `ipl_remove':
> ../../netinet/mln_ipl.c:189: too few arguments to function `VOP_LOCK'
> ../../netinet/mln_ipl.c:197: too few arguments to function `VOP_LOCK'
> ../../netinet/mln_ipl.c:205: too few arguments to function `VOP_LOCK'
> *** Error code 1
> 
> Stop.                                                                     
> 
> --
> Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de

This is because VOP_LOCK takes three arguments, starting with
4.4BSD-lite2. I didn't like this use of vnodes to create and remove
/dev/ip{l,nat,state}, each time the module is loaded/unloaded,
which is why I didn't include them when I wrote mlf_ipl.c
(ipfilter-proff-final2.shar etc). It strikes me as needlessly
complex, and crossing domains (i.e it is not proper for network
software to be messing with the file system), and interfering with
user defined policy (tripwiring, write-protecting etc of /dev). If
there is no agreed on assigned major number - and there *is* in
the case of {Net,Free,Open}BSD) - the proper course is to 
have a user-level program grovel through kmem, or otherwise examine
the major number resource, and execute a standard mknod, not the
VOP_* horror we currently see.

Cheers,
Julian.