From owner-freebsd-hackers Thu Apr 10 10:04:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17895 for hackers-outgoing; Thu, 10 Apr 1997 10:04:46 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17882 for ; Thu, 10 Apr 1997 10:04:42 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA09371; Thu, 10 Apr 1997 09:42:56 -0700 From: Terry Lambert Message-Id: <199704101642.JAA09371@phaeton.artisoft.com> Subject: Re: ipfilter/2.2.1 / devfs (general) To: bde@zeta.org.au (Bruce Evans) Date: Thu, 10 Apr 1997 09:42:55 -0700 (MST) Cc: mishania@demos.su, proff@suburbia.net, hackers@freebsd.org In-Reply-To: <199704100302.NAA16451@godzilla.zeta.org.au> from "Bruce Evans" at Apr 10, 97 01:02:35 pm X-Mailer: ELM [version 2.4 PL24] 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 > Ifdefed options are fundamentally incompatible with LKMs. This means > that LKMs must not use nonstandard options like DEVFS, except possibly > if you keep the LKMs carefully synchronised with the kernel. And this is a problem with #ifdef'ed options, not with LKM's. > The IPFILTER and IPFILTER_LKM options are more of a problem than DEVFS > because they affect standard objects (ip_input.o and ip_output.o). A > GENERIC kernel can't possibly support an ipfilter LKM since GENERIC > isn't configured with these options. The corresponding problem for > ipfw is handled by using a negative option - COMPAT_IPFW defaults to 1. This has more to do with what should and should not be replaceable with a function point; it has more to do with the organization of the network code than with IPFILTER/IPFW. If you could replace the function entirely, it wouldn't need the #ifdef's. > The corresponding problem for file systems is very old and usually > not worried about. The union filesystem can't be an LKM because of > a couple of `#ifdef UNION's in "machine-independent" code. The ext2fs > filesystem can't be an LKM because of many `#ifdef EXT2FS's in ufs. The UNION stuff is a result of an incorrect implementation of the getdirentries() code in kern/vfs_syscalls.c, and a corresponding bogosity in the iplementation of the union specific VOP_READDIR(). It is the inability to agregate cookie values from two or more file systems that makes the union_readdir() broken. The inability to agregate, in turn, comes from the use of a user buffer for the cookie copies. VOP_READDIR() needs an overhaul, and to be split into two (or perhaps even more) seperate VOP operations. The EXT2FS code, is, from what I can see, compile time dependent, not implementation time dependent. If you look at the Lite2 CD9660 code, there are rumblings of ntegrating that into the UFS stuff as well, on the same basis. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.